1

Well, the problem is how to organize assemblies for several WCF services hosted in the same domain, when the services might use different versions of the same referenced assemblies?

The thing is, that I have a series of WCF services which are currently hosted in the same domain, but the burden of updating one of these services is overwhelming due to the fact that I cannot be sure not to break other services when doing so. Therefore, it requires that I bring all other services up-to-date with the new version of assembly or assemblies which I am going to publish.

Updating the service - in my case - would be do change one or more assemblies in the bin folder. The problem is that other services might need the same assemblies. I would like to have the possibility of defining subfolders with the name of the service, and in each of these folder have a bin subfolder, the .svc file and all other stuff related to the service. This way I could isolate the service on the same domain.

I have searched for a solution and I have found a blog post by Scott Hanselman about probing, but it seems to apply to .NET 1.1, ASP.NET...

http://www.hanselman.com/blog/PermaLink.aspx?guid=4d0ef4fb-f8ae-4355-a658-3c0432c98dbe

Unfortunately, I cannot make it work for my scenario (.NET 4.0). Furthermore, I am not sure that this would scale the way I need. Even if I could make it work, then is it going to be seperate AppDomains, and if not would that be a problem? I need the complete isolation of the service, but still being hosted in the same domain.

Thanks, Jacob.

Update

Actually, I got a bit further. I tried to put the [ServiceName].svc.cs and the interface into its own project and compile it, and then change the .svc file slightly to reference the assembly just created as described by Hanselman. If I leave out the Import statement also mentioned in his post and doing the other bits aswell, then it actually works.

The only thing is if I have a list of paths, something like...

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <probing privatePath="Tasks\bin;Products\bin"/>
    </assemblyBinding>
</runtime>

... then can I be sure that the assemblies used are from the right folder, and not resolved in the order they appear in the list? An example could be if the ProductsService uses the same assembly as TaskService but in a different version, then if the assembly is resolved in the order they appear in the privatePath string above then it would use the wrong assembly I guess? Then it is not completely isolated after all.

If I am right in this assumption, then perhaps strong-naming is the answer?

Thanks again, Jacob.

4

1 回答 1

0

我相信您需要的是服务版本控制而不是探测。

您的客户端需要通过网络使用相同服务的不同版本。这是一个常见问题，由Service Versioning解决。所以他们没有引用 DLL，他们连接到服务。

因此，您只需创建一个新版本，部署到新端点并使用新服务获取新客户端。

于 2011-04-07T22:01:44.000 回答