.Net 在两个 Web 服务之间共享 dll答案

【问题标题】：.Net share dll's between two Web Services.Net 在两个 Web 服务之间共享 dll
【发布时间】：2011-08-28 00:42:23
【问题描述】：

我有两个 Web 服务都包含在一个公共子目录下

CompanyName\Service1
CompanyName\Service2

每个目录都有一个包含其 dll 的 bin 文件夹。我现在已经到了这样一个地步，其中一些代码已经过重组，并且有相当多的通用组件，我希望能够“共享”它们。解决此问题的最佳方法是什么？下面是我找到的解决方案列表（连同否定的）。

AssemblyResolving - 安全问题。
codeBase web.config 中的元素 - 组件位置的硬编码路径。
GAC - 目前我们的产品都没有使用 GAC，我个人对使用它的了解非常有限。这可能只是对未知的恐惧。
在两个位置都放置组件 - 更难更新就地补丁。需要确保在所有位置替换文件。

我是否遗漏了其他可能对我有帮助的内容？有人会推荐使用上面列出的任何选项吗？

此外，我无法将这两项服务合并为第三方当前使用的服务（它们是单独构建的）。

【问题讨论】：

如果您不经常更改 dll 的代码，则将程序集放置在这两个位置。或者，如果您有 dll 的自动构建过程，请让构建脚本尽可能将输出 dll 复制到两个文件夹中。
您对两个位置的注释“更难就地更新补丁”实际上是错误的方法。通过共享同一个物理程序集，如果公共程序集需要更改接口或有其他一些重大更改，那么协调对一个或其他 Web 服务的更改会变得更加困难。
我不明白...您不能将两个项目的引用添加到包含共享代码的新项目中吗？当构建特定项目之一时，引用将导致构建共享项目
@Simeon：是的 - 编码/构建时管理（两个 Web 服务使用的单独的类库项目，由 IDE/构建过程自动维护）和部署管理（更安全）之间可能存在一些混淆分别更新每个 Web 服务及其核心代码版本）。

标签： c# iis components share

【解决方案1】：

我会选择 GAC，因为它可以解决您列出的所有其他问题，此外，共享库位于一个位置看起来很自然。

要使用 GAC，您只需要对 dll 进行强命名，并在安装时将其放入 GAC 它还为您提供了良好的并行版本控制选项（一个 WS 使用版本 1.0.0.0 ，另一个可以使用 1.0.0.1）

【讨论】：

只需添加一个警告，即项目将继续查看 GAC 中的旧版本，直到使用新版本重新编译，或者更新 web.config 以包含 assemblyRedirect 条目以强制使用新版本。
正确 - 每次您需要部署具有重大更改的核心代码时，在 GAC 中注册的部署开销远远超过了复制共享代码程序集的缺点（在我看来，因此我们有单独的答案:))。
@Andy - 不是默认的程序集参考选项 - 使用最新版本？
@Meanahem，一旦程序集被强命名。然后，默认情况下，它与特定版本相关联。每次增加版本时，都必须在 Visual Studio 中删除并重新添加引用。真是太痛苦了 :( 我们尝试在整个堆栈中的一些开源项目中做强命名程序集，但这太麻烦了。现在你可以通过在之后签署一个 ilmerged 程序集来作弊。
Travis 是对的，针对强命名程序集进行构建将其与特定版本联系起来。

【解决方案2】：

最好的办法是几乎可以肯定地同时更新这两项服务。如果这让您担心，请查看您的部署过程。

另一个真正的选择是使用 GAC。 GAC 有它自己的问题，例如必须强名称/签署您的程序集和更多部署问题。

关于构建系统，如果您总是同时构建和部署两个 Web 服务，那么您不必担心混合匹配，因为您指出程序集需要在服务之间保持相同。如果您不使用 CI 系统，我建议您开始一个，TeamCity 是一个很好的开始，它是免费的（好吧，对于有限数量的用户/项目 - 足以让您入门）。然后直接从 CI 部署，或者从那里生成的包进行部署。我承认 CI 解决一个问题有点难，但如果你从长远来看，它可以帮助你的生活更轻松。

【讨论】：

【解决方案3】：

这就是 GAC 的目的所在。

如果您想协调共享代码，也可以创建私有 NuGet 提要。

http://haacked.com/archive/2010/10/21/hosting-your-own-local-and-remote-nupack-feeds.aspx

http://haacked.com/archive/2011/01/15/building-a-self-updating-site-using-nuget.aspx

【讨论】：

不确定 GAC 是为了让 ASP.Net 部署更易碎/更复杂 ;) - 但自更新网站的概念非常酷！

【解决方案4】：

两个位置。这样，您可以通过替换该 bin 文件夹中的文件，在一个版本中发布对公共代码的更改（接口更改/中断更改），而不会危及/破坏其他 Web 服务。

更新：这与使用 GAC 具有相同的“并行版本控制”优势，没有任何协调的发布复杂性、严格的命名要求等。

【讨论】：

【解决方案5】：

另一种选择是将文件放在一个位置并使用符号链接链接到它们。 This 线程解释了命令。

我没有尝试过这个的经验，所以不推荐它。

【讨论】：

坏主意 - 当核心代码发生重大变化时，这会强制两个 Web 服务同时更新。 GAC 解决方案混乱/繁重，但在正确应用时是安全的，重复部署既安全又简单。