Question

我们在所有（许多）内部应用程序中使用log4net。我们通常会执行相当于xcopy部署的操作。为方便开发人员，我们将log4net源编译为我们的核心库之一。

现在又回来咬我们了。其他开源库（例如Topshelf）引用log4net。还有一些（例如NServiceBus）将log4net合并到它们的程序集中。通常版本不同。

这是一个普遍的问题;特定的图书馆就是例子。

有几个类似的问题：

在各种解决方案（GAC，assemblyBinding，bindingRedirect等）中，未来可能会给我们带来最小的痛苦？我们可以修改我们的核心库;我们无法做任何会破坏现场部署版本的事情。更新我们所有的项目参考将是痛苦的，所以我们只想这样做一次。

更新：Topshelf的当前版本抽象了日志记录，因此这不再是该框架的问题。

Answer 1

我一直处理多个引用，并帮助轻松升级它们的一个鲜为人知的/已使用的功能是Reference Paths与绑定重定向相结合。使用引用路径，我能够在源代码管理中的单独的类库/包中维护一个共享库，它包含我们正在使用的依赖库。

拥有自己的文件副本，单独控制（通常需要在共享库文件夹中包含 .license 文件，如果它是付费库），允许新开发人员快速确保他们在其计算机上安装了正确的版本，而不会与计算机上已有的库发生冲突。

此方法有一个警告，即您添加的任何其他参考路径都不会存储在 .csproj 文件中，而是 .csproj.user 文件。

在许多开箱即用的源代码管理解决方案中，例如Team Foundation Server或Vault;默认情况下，这些文件不包含在签入过程中。大多数源代码控制提供程序，包括提到的两个提供程序，都可以选择更改每个项目以及全局的受控文件扩展名。

唯一的另一个警告是一些源控制提供程序，例如Vault，默认情况下将 .csproj 和 .csproj.user 文件视为二进制文件;再次，这可以改变，它们可以在Vault的情况下被视为XML，允许合并。

它们在Team Foundation Server中被视为XML开箱即用。

Answer 2

在您的情况下，我会使用Publisher Assembly Policy

在GAC中部署我的DLL

发布者策略程序集是一个程序集，用于配置.NET运行时绑定到程序集时要使用的策略。因此，您可以通过在发布者策略中指定必须使用哪个版本的DLL来轻松更新所有项目。

发布商汇编政策示例：

<configuration> 
<runtime>
 <assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″>
  <dependentAssembly> 
   <assemblyIdentity name=”website” publicKeyToken=”18517ea673f8584b” culture=”neutral” />
   <bindingRedirect oldVersion=”1.0.0.0″ newVersion=”2.0.0.0″/> </dependentAssembly> 
</assemblyBinding> 
</runtime> 
</configuration>

Answer 3

有一个NServiceBus，它不会合并第三方程序集。

来自the download page：

合并程序集的问题？

为了减少开发人员需要在其Visual Studio项目中引用的程序集数量，NServiceBus将多个第三方程序集合并到自己的程序集中。如果开发人员在自己的代码中使用这些第三方程序集，这可能会导致冲突 - 特别是在使用与NServiceBus附带的版本不同的版本时。

为了解决这个问题，开发人员应该使用＆＃34;仅核心＆＃34; NServiceBus的程序集。对于购买了商业NServiceBus许可证和支持包的公司，这些组件可以在＆＃34; core-only＆＃34;目录。

如果您正在使用快速版，则需要下载源代码（上图）并使用＆＃34; UnsupportedBuildCoreOnly.bat＆＃34;自行编译。文件。

流行的开源库和引用冲突

3 个答案:

合并程序集的问题？