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

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

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

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

我搜索了一个解决方案，发现了Scott Hanselman关于探测的一篇博文，但它似乎适用于.NET 1.1、ASP.NET

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

谢谢，雅各布

更新

事实上，我走得更远了。我尝试将[ServiceName].svc.cs和接口放入自己的项目中并编译它，然后稍微更改.svc文件以引用Hanselman刚刚创建的程序集。如果我省略了在他的帖子中提到的Import语句，并做了其他的部分，那么它实际上是有效的

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

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

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

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

---

再次感谢你，雅各布。

我相信你需要的不是探究

您的客户端需要通过网络使用同一服务的不同版本。这是一个常见问题，由服务版本控制解决。因此，它们不是引用DLL，而是连接到服务

---

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

谢谢，但它实际上是不同的服务，而不仅仅是不同的版本，例如TaskService、ProductService、EmailService等等，谢谢。事实上，我想我走得更远了。几分钟后在原始帖子中看到更新…您不能创建子应用程序吗<代码>http://myendpoint.mycompany.com/Tasks/TaskService.svc和

http://myendpoint.mycompany.com/Products/ProductsService.svc

？这样他们就不会互相干扰了。谢谢你，约翰，很抱歉解释得不够好。你的建议就是我实际正在做的。但是，每个服务只有一个子文件夹，程序集仍必须位于根目录的bin文件夹中。可能令人困惑的是，它不仅是服务的程序集，而且是我自己的库，例如MyCompany.Security.dll、MyCompany.Web.dll等，它们可以在不同版本的服务中引用。无论如何，谢谢你，雅各布。@Jacob：每个文件夹做一个项目-每个都是一个IIS应用程序，所以每个都有自己的bin文件夹。他们仍然可以共享公共代码。嗨，约翰。一对一项目？你的意思是我应该把一个服务的所有代码放在一个DLL中吗？如果是这样的话，那将不是一个最佳的解决方案，因为我的代码在库中组织得很好，这是被引用的。或者你的意思是在同一个虚拟文件夹下做单独的虚拟文件夹或者类似的事情？@Jacob：每个服务一个项目，这些项目可以引用库，这些库可以保持良好的组织。