组件 //多个客户端引用的第三方/公共组件， //例如， NUnit的，MVC：
[VENDORNAME] [库名称] [VERSIONNUMBER]
你已经打开了被誉为 “如何处理我的二进制依赖” 蠕虫即可。
并试图找到一个处理该问题的SVN解决方案。
所以你想弄清楚快速修复？或者你准备好投入一些时间了吗？
.......
“常春藤”从阿帕奇一直在处理二进制依赖问题，因为2005年“的NuGet”登上了几年前。
让我们来看一个简单的例子。
您有一个名为“MyPDFHelper.dll”（最初版本1.0.0.1）第三方库。 您有2个解决方案，每个解决方案包含3个项目。 （VS.sln和.csproj）。
Sln1, CSProjA, CSProjB, CSProjC
Sln2, CSProjW, CSProjX, CSProjY
Sln1/CSProjA depends on MyPDFHelper.dll, 1.0.0.1.
Sln2/CSProjX depends on MyPDFHelper.dll, 1.0.0.1.
PDFHelper发布MyPDFHelper.dll 1.0.0.2的新版本。没有突破的变化，一切都很酷。
PDFHelper发布MyPDFHelper.dll 2.0.0.1的新版本。 随着变化。
上Sln2/CSProjX开发人员希望使用MyPDFHelper.dll，2.0.0.1。 但是这将如何影响没有计划从1.0.0.1更新的Sln1/CSProjA。
显然，您已经看到此问题，因为您有[VersionNumber]。
但这是一个哲学问题。 SVN是为源代码（基本上是文本文件）还是源代码和二进制存储库的组合创建的？
Ivy和Nuget是BINARY存储库。
现在，我使用常春藤（即使在微软的世界），因为我解决了依赖性问题之前的短语'Nuget'曾经发出。
......
这是一个稍微不同的问题，但类似。
您有相同的“应用程序”项目。
Sln1, CSProjA, CSProjB, CSProjC
Sln2, CSProjW, CSProjX, CSProjY
但是你也有一个.sln“框架”一块。 假设它是封装良好的电子邮件发送代码。
MyCompany.EmailLibrary.sln MyCompany.EmailLibrary.csproj 它建立成MyCompany.EmailLibrary.dll
Sln1/CSProjB uses MyCompany.EmailLibrary.dll.
Sln2/CSProjX uses MyCompany.EmailLibrary.dll.
当您在自己的框架件重大更改，会发生什么？
.........
所以简而言之，
而不是把代码放到你的源代码库，你
“发布”在我们的例子中的二进制库
：
MyPDFHelper.dll, 1.0.0.1. would be published
MyPDFHelper.dll, 1.0.0.2. would be published
MyPDFHelper.dll, 2.0.0.1. would be published
，然后将每个项目“依赖在“MyPDFHelper.dll上，它会有一些配置值，说”我想使用这个版本的MyPDFHelper.dll“。
常春藤符号会像
“1.0.0+” 或 “1+”。
当2.0.0.1是“发布”时，Sln2的配置可以更改为“2.0.0+”。 Sln1配置保持不变，“1.0.0+”
这样，每个Sln（1和2）将“检索”符合他们需要的MyPDFHelper.dll版本。 最终（当开发人员选择这样做时）Sln1可以更改为“2.0.0+”，但开发人员可以在他/她想要时处理重大更改，而不是其他开发人员放置新的第三方dll时进入源代码控制。
.........
现在，当涉及到MyCompany.EmailLibrary.dll。 基本上，每次创建MyCompany.EmailLibrary.sln时，都会将新构建放入二进制存储库。如果你所做的只是bug修复，那么你总是可以发布（并覆盖）版本“1.0.0.1”，但我更愿意使用递增数字发布。
MyCompany.EmailLibrary.dll v 1.0.0.333
MyCompany.EmailLibrary.dll v 1.0.0.334
MyCompany.EmailLibrary.dll v 1.0.0.444
（数字不”的事情，只是他们递增事实。
.........
我会检查出Nuget（带有私有存储库）或Ivy（使用COMMAND LINE选项）。
我没有给你一个确切的解决方案，而是我向您介绍的二进制库的概念。
===================编辑
至于 “源代码结构”，我这样做：
\DotNet\src\v20Base\v20\
\DotNet\src\v20Base\v20\Applications\
\DotNet\src\v20Base\v20\Framework\
\DotNet\src\v20Base\v20\ThirdParty\
\DotNet\src\v20Base\v35\
\DotNet\src\v20Base\v35\Applications\
\DotNet\src\v20Base\v35\Framework\
\DotNet\src\v20Base\v35\ThirdParty\
\DotNet\src\v40Base\v40\
\DotNet\src\v40Base\v40\Applications\
\DotNet\src\v40Base\v40\Framework\
\DotNet\src\v40Base\v40\ThirdParty\
\DotNet\src\v40Base\v45\
\DotNet\src\v40Base\v45\Applications\
\DotNet\src\v40Base\v45\Framework\
\DotNet\src\v40Base\v45\ThirdParty\
Example Application
\DotNet\src\v40Base\v40\Applications\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\SodaManagerSolution.sln
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\Pres.AspNet\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\Pres.WPF\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\BusinessLogic\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\DataLayer\
\DotNet\src\v40Base\v40\Applications\SodaManagerSolution\SqlScripts\
Example Framework
\DotNet\src\v40Base\v40\Framework\
\DotNet\src\v40Base\v40\Framework\MyCompany.EmailLibrary\
\DotNet\src\v40Base\v40\Framework\MyCompany.EmailLibrary\MyCompany.EmailLibrary.sln
\DotNet\src\v40Base\v40\Framework\MyCompany.EmailLibrary\MyCompany.EmailLibrary.csproj
DOTNET的3.5 （和3.0）在2.0之后是“覆盖”。因此，3.5解决方案可以使用2.0 dll而没有问题。 4.0是一个新的CLR，因此新的“v40Base”。
它可能感觉过度杀伤，但是当框架在一个大的源代码库中改变.......它开始混淆哪个项目可以引用哪个其他项目。