我们有许多 c# 项目都依赖于一个通用的 DLL（也是 c#）。当我们处于需要能够频繁构建和部署更新代码的环境中时，此 DLL 会发生一些变化。这样做的问题是，如果其中一个更新需要更改公共 DLL，我们最终会得到几个客户端应用程序，它们的 DLL 版本都略有不同。
我们正试图弄清楚如何改进此设置，因此我们可以保证任何人都可以签出项目（我们使用 SVN）并能够毫无问题地构建它。似乎将每个 DLL 更改标记为新版本是过度的，但我不确定“正确”的解决方案是什么（或至少是优雅的）。
如果任何解决方案允许开发人员能够从 Visual Studio 进入 DLL 代码，那将是理想的，这似乎只有在您的机器上有项目本身时才有可能（那里可能是错误的）。
【问题讨论】：
标签： c# svn dependencies
坦率地说，我认为在源代码控制中对 DLL 进行版本控制是正确的解决方案。
快速更改的核心 DLL 很可能会导致客户端项目中的二进制文件和源代码兼容。通过版本控制，您可以阻止每个项目使用新的 DLL，直到您准备好迁移。
这提供了一定程度的安全性 - 您知道您不会因为其他人更改了您下面的内容而破坏客户的项目，但随时升级到新版本非常容易。
SVN 中的版本控制是微不足道的 - 所以我不会让这成为一个问题。从业务的角度来看，它也更安全，因为您有一个非常清晰的“书面记录”来说明客户项目的给定可交付成果所使用的版本，这在计费、跟踪、可测试性等方面有很多好处。
【讨论】：
没有简单的解决方案 - 前两个答案可能是实现您想要的更可接受的方法。如果您有一个 CI 环境，并且能够从通过 CI 构建的商店按需推出所有应用程序，那么您可以避免这个问题。但是，如果其中有不受测试等管理的旧应用程序，那可能是一个崇高的目标。
如果您的应用程序是 .Net 3.5（甚至可能还需要 SP1），那么您是否知道从网络加载的程序集现在不再有任何信任限制？这意味着您可以在相关机器上配置一个程序集路径以指向一个共享的、高度可用的网络位置 - 并让您的所有应用程序从那里定位程序集。
对此的替代方案，但可以实现相同的目标，是构建一个挂钩到 AppDomain.CurrentDomain.AssemblyResolve 事件的组件 - 当运行时无法自动发现程序集时触发该事件 - 并执行在该网络位置手动搜索有问题的 dll（如果您要获取全名的 AssemblyName 部分，请将 .dll 附加到它，那么您将重现 .Net Fusion binder 执行的相同搜索） .
只是一个想法；）
【讨论】：
我认为您可以从为每个客户端项目和公共 DLL 项目设置目标的持续集成服务器中受益。
这样，您将立即知道公共 DLL 中的更改何时会破坏任何客户端项目。可以减少常用DLL接口发生变化时更新客户端项目的麻烦。如果您的开发团队分散且非常庞大，则此解决方案可能不合适。
我不会说有一个正确的解决方案。管理依赖问题的方法有很多。
您也可以看看 Maven。它将帮助您设置项目依赖项。不确定如何将 Maven 集成到 Visual Studio 中。 Maven 将允许您指定要依赖的项目版本（在 SVN 中）。然后，开发人员将能够检查正确的项目版本并构建他们的项目。 Maven 将从 SVN 中为它们检查正确版本的依赖项目。我自己没用过，但是 Java 社区的很多开源项目都在用它。
【讨论】：