svn 外部和 c# 程序集 - 不兼容？
在 .net 中本应如此简单的事情似乎非常困难。
我有一个名为 MyExtenders 的项目，其中包含一些基本类型的简单扩展程序。
许多项目都使用 MyExtenders - 因此在传统的 svn 签出和构建方法中，我将 MyExtenders 添加为 svn:external，并将修订版锁定到最后构建和测试的版本。
现在，如果我有两个项目都需要将 MyExtenders 添加到同一个解决方案中，那么它们都会落在堆中。我无法将两个 MyExtender 添加到解决方案中 - 所以我必须只使用一个 - 在不同修订的情况下意味着用它重新测试旧项目。
一个图表可能最好地解释了依赖关系：
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，以及不同的修订版。
显然我做错了..但是你如何做对呢？
something that should be so simple in .net seems to be oh-so-hard.
I have a project called MyExtenders, containing a few simple extenders to basic types.
Many projects use MyExtenders - and so in traditional svn checkout and build approach I add MyExtenders as an svn:external with the revision locked to whichever it was last built and tested at.
Now if I have two projects both requiring MyExtenders added to the same solution it all falls in a heap. I cannot add both MyExtenders to the solution - so I have to use just one - which in the case of different revisions means re-testing the older project with it.
A diagram possibly best explains the dependencies:
SolutionA
->ProjectA
->->MyExtenders r350 (svn:externed by ProjectA)
->ProjectB
->->MyCryptography r800 (svn:externed by ProjectB)
->->->MyExtenders r800 (svn:externed by MyCryptography)
Delphi/C work with the above just fine - all references are from their own project folder.
VS insists on losing the directory structure and flattening the above to:
SolutionA
->ProjectA (refers MyExtenders)
->ProjectB (refers MyCryptography)
->MyCryptography r800 (refers MyExtenders)
->MyExtenders r350 || r800 - my choice
And me being forced to modify one of the projects to refer to a different MyExtenders, and a different revision at that.
Clearly I'm doing it all wrong.. but how do you do it right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
确实没有办法解决这个问题：如果您有两个不同的项目依赖于同一程序集的不同版本，那么无论您如何管理项目间依赖关系，都必然会发生冲突。要了解这是为什么，想象一下您所有的源冲突都可以以某种方式解决 - 现在您将在部署时做什么？加载依赖项的哪个程序集版本？无论是哪一个，它都可能会破坏需要其他版本的依赖程序集。
如果您的设计需要在各个子系统之间使用共享库，并且这些子系统位于同一个进程中（好吧，从技术上讲，是同一个 AppDomain），那么您需要为两个子系统提供相同的程序集版本。
如果您可以将依赖程序集通过边界（例如服务接口或远程处理通道）分隔开，那么这个问题就会消失。然后您可以独立对依赖项进行版本控制。然而，Visual Studio 不喜欢在一个解决方案中拥有两个同名的项目，因此解决此问题的唯一方法是复制其中一个项目文件，重命名它，然后将其加载到解决方案中。
There really is no way around this: if you have two different projects depending on different versions of the same assembly, you are bound to have conflicts regardless of how you manage the inter-project dependencies. To see why this is, imagine that all your source conflicts could be solved somehow - now what will you do upon deployment? Which assembly version of the dependency gets loaded? Whichever it is, it will likely break the depending assembly which needs the other version.
If you have a design which requires a shared library among various subsystems, and those subsystems live in the same process (ok, technically, the same AppDomain), you need to have the same assembly version for both.
This problem goes away if you can get the depending assemblies separated by a boundary, such as a service interface or remoting channel. Then you can version the dependencies independently. Visual Studio will not like having two projects in one solution with the same name, however, so the only way around this is to copy one of the project files, rename it, and load it into the solution.