一些在 .net 中应该如此简单的事情似乎很难。
我有一个名为 MyExtenders 的项目，其中包含一些基本类型的简单扩展器。
许多项目使用 MyExtenders - 因此在传统的 svn check out 和构建方法中，我将 MyExtenders 添加为 svn:external，并将修订锁定到最后构建和测试的版本。
现在，如果我有两个项目都需要将 MyExtenders 添加到同一个解决方案中，那么它们都会陷入困境。我不能将两个 MyExtenders 添加到解决方案中 - 所以我必须只使用一个 - 这在不同修订的情况下意味着用它重新测试旧项目。
一张图可能最好地解释了依赖关系:
SolutionA
->ProjectA
->->MyExtenders r350 (svn:externed by ProjectA)
->ProjectB
->->MyCryptography r800 (svn:externed by ProjectB)
->->->MyExtenders r800 (svn:externed by MyCryptography)
Delphi/C 可以很好地处理上面的内容——所有引用都来自它们自己的项目文件夹。
VS 坚持丢失目录结构并将上面的扁平化为:
SolutionA
->ProjectA (refers MyExtenders)
->ProjectB (refers MyCryptography)
->MyCryptography r800 (refers MyExtenders)
->MyExtenders r350 || r800 - my choice
我被迫修改其中一个项目以引用不同的 MyExtenders，并在那个地方进行不同的修订。
显然我做错了..但你如何做对呢？
最佳答案
确实没有办法解决这个问题:如果您有两个不同的项目依赖于同一个程序集的不同版本，那么无论您如何管理项目间的依赖性，都必然会发生冲突。要了解这是为什么，想象一下您所有的源冲突都可以以某种方式解决 - 现在您将在部署时做什么？加载依赖项的哪个程序集版本？无论是哪种，它都可能会破坏需要其他版本的依赖程序集。
如果您的设计需要在各个子系统之间共享库，并且这些子系统位于同一进程中(好吧，从技术上讲，是相同的 AppDomain)，您需要为两者使用相同的程序集版本。
如果您可以让依赖的程序集被边界分隔开，例如服务接口(interface)或远程处理 channel ，这个问题就会消失。然后您可以独立地对依赖项进行版本控制。然而，Visual Studio 不喜欢在一个解决方案中有两个同名的项目，因此解决此问题的唯一方法是复制其中一个项目文件，重命名它，然后将其加载到解决方案中。
关于c# - Svn 外部和 C# 程序集 - 不兼容？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3170468/