为同一域中的多个 WCF 服务组织程序集

发布于 2024-10-31 05:52:00 字数 1544 浏览 1 评论 0原文

那么，问题是当服务可能使用相同引用的程序集的不同版本时，如何组织同一域中托管的多个 WCF 服务的程序集？

问题是，我有一系列当前托管在同一域中的 WCF 服务，但更新其中一个服务的负担是巨大的，因为我不能确定不更新这样做时会破坏其他服务。因此，它要求我将所有其他服务与我要发布的新版本的程序集或程序集保持同步。

更新服务 - 就我而言 - 将更改 bin 文件夹中的一个或多个程序集。问题是其他服务可能需要相同的程序集。我希望能够使用服务名称定义子文件夹，并且在每个文件夹中都有一个 bin 子文件夹、.svc 文件和所有其他内容与服务相关。这样我就可以隔离同一域上的服务。

我搜索了一个解决方案，并找到了 Scott Hanselman 撰写的关于探测的博客文章，但它似乎适用于 .NET 1.1、ASP.NET< /em>...

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

不幸的是，我无法让它适用于我的场景（.NET 4.0）。此外，我不确定这是否会按照我需要的方式进行扩展。即使我能让它工作，那么它是否会是单独的AppDomains，如果不是，那会是一个问题吗？我需要服务的完全隔离，但仍托管在同一域中。

谢谢，雅各布。

更新

实际上，我更进一步了。我尝试将 [ServiceName].svc.cs 和接口放入自己的项目中并编译它，然后稍微更改 .svc 文件以引用程序集按照 Hanselman 的描述创建。如果我省略他的帖子中提到的导入语句并执行其他操作，那么它实际上是有效的。

唯一的问题是，如果我有一个路径列表，例如......

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

那么我可以确定所使用的程序集来自正确的文件夹，并且不是按照它们在列表中出现的顺序解析的吗？例如，如果ProductsService使用与TaskService相同的程序集，但版本不同，那么如果程序集按照它们在privatePath中出现的顺序进行解析 上面的字符串那么我猜它会使用错误的程序集？那么它毕竟不是完全孤立的。

如果我的这个假设是正确的，那么也许强命名就是答案？

再次感谢，雅各布。

原文

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.

分享到QQ

分享到微博