处理对频繁变化的DLL的依赖性

Question

我们有许多c＃项目都依赖于一个共同的DLL（也是c＃）。当我们需要能够经常构建和部署更新代码的环境中时，这个DLL会稍微改变频率。问题是，如果其中一个更新需要更改常见的DLL，我们最终会得到几个客户端应用程序，这些应用程序的DLL版本略有不同。

我们正试图弄清楚如何改进此设置，因此我们可以保证任何人都可以检查项目（我们使用SVN）并且能够毫无问题地构建它。似乎标记每个DLL更改为新版本的过多，但我不确定“正确”的解决方案是什么（或者至少是优雅的）。

如果任何解决方案允许开发人员能够从visual studio进入DLL代码，这将是理想的，如果您的计算机本身在您的计算机上（这可能是错误的），这似乎是可能的。

Answer 1

坦率地说，我认为在源代码管理中对DLL进行版本控制是正确的解决方案。

快速更改的核心DLL很可能会导致客户端项目中的二进制和源兼容性。通过版本控制，您可以阻止每个项目使用新的DLL，直到您准备好迁移为止。

这提供了一定程度的安全性 - 你知道你不会破坏客户的项目，因为有人改变了你下面的东西，但是随时升级到新版本很容易。

SVN中的版本控制是微不足道的 - 所以我不会让这成为一个问题。从业务角度来看，它也更安全，因为您对客户项目的给定交付项使用了什么版本有一个非常明确的“文件记录”，它在计费，跟踪，可测试性等方面有许多好处。

Answer 2

没有简单的解决方案 - 之前的两个答案可能是更容易实现您想要的方法。如果您有一个CI环境，并且能够从通过CI构建的商店按需推出所有应用程序，那么您可以避免此问题。但是，如果那里的旧应用程序没有受到测试等的支配，那么这可能是一种崇高的抱负。

如果您的应用程序是.Net 3.5（甚至可能还需要SP1），那么您是否知道从网络加载的程序集现在不再具有任何信任限制？这意味着您可以在相关计算机上配置程序集路径以指向共享的，高可用性的网络位置 - 并让所有应用程序从那里找到程序集。

替代它，但实现相同的目标，是构建一个挂钩到AppDomain.CurrentDomain.AssemblyResolve事件的组件 - 只要运行时无法自动发现程序集就会触发 - 并且在该网络位置手动搜索有问题的DLL（如果您要使用全名的AssemblyName部分，将.dll附加到它，那么您将再现.Net Fusion活页夹执行的相同搜索）

只是一个想法;）

Answer 3

我认为您可以从为每个客户端项目和常见DLL项目设置目标的持续集成服务器中受益。

通过这种方式，您可以立即知道公共DLL中的更改何时会破坏任何客户端项目。当常见的DLL接口发生变化时，它可以减少更新客户端项目的麻烦。如果您的开发团队分布且非常大，那么此解决方案可能不够充分。

我不会说有一个正确的解决方案。有很多方法可以管理依赖性问题。

你也可以看看Maven。它将帮助您设置项目依赖项。不知道如何将Maven集成到Visual Studio中。 Maven将允许您指定要依赖的项目版本（在SVN中）。然后，开发人员将能够签出正确的项目版本并构建他们的项目。 Maven将为他们检查SVN的依赖项目的正确版本。我自己没有使用它，但Java社区中的许多开源项目都使用它。