好的，这就是场景。
项目A有一个为它开发的类库（我们称之为MyLib）。我发布了MyLib版本1的项目A（内部项目）。
我在Project B上开始开发，但是将MyLib扩展到版本2，包括对现有类型的一些优化。
如果我将Mylib 2发布到项目A和项目B，我将不得不重新编译项目A以支持类型更改，是否有人能够获得经过验证且真实的解决方案？
答案 0 :(得分：4)
您可以尝试assembly redirection并让Project A加载您库的较新版本。这需要您将重定向信息添加到运行应用程序的所有计算机的配置中，但您不必重新编译。您可以在应用程序配置文件中或在计算机级别执行此操作。
文章内容的那篇文章的例子：
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="myAssembly"
publicKeyToken="32ab4ba45e0a69a1"
culture="en-us" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
当然，如果您在新版本中破坏了与原始库的兼容性，则无法使用。
答案 1 :(得分：3)
如果您不喜欢@ Steven的程序集重定向方向，并且假设您不想重新编译项目A，则可以私下将不同版本的MyLib部署到每个项目。
然后，项目A将继续使用版本1，而项目B将使用版本2.这似乎是您想要听到的 - 并且这是微不足道的。将MyLib dll放在每个项目的文件夹（或子文件夹）中，每个项目将自动获取相应的本地版本，或者您可以在GAC中对它们进行强名称，并让每个项目选择您编译的特定版本。
这实际上是默认行为，您无需执行任何复杂操作即可实现此目的。
答案 2 :(得分：3)
为MyLib提供strong name和install it to the GAC。 GAC可以具有相同程序集的多个版本。它需要为MyLib的版本1（不仅仅是版本2）提供强名称。
项目A需要MyLib的第1版并在GAC中找到它。项目B需要MyLib的第2版并在GAC中找到它。每个人都很高兴，你不必在使用它们的程序集的相同目录中保存30份不同版本的MyLib，重新创建DLL-hell。
我知道AviD也提到了GAC，但作为可执行文件的私有副本的替代品。我认为应该避免这种情况。
答案 3 :(得分：1)
我的建议：持续整合。
使用像CruiseControl.NET这样的工具，您可以重建每个项目/解决方案，甚至将一个（.dll）的输出上传到Source COntrol以供其他项目使用，每个单元测试运行一次时间，以便您可以检查解决方案A中使用的项目中的添加/编辑是否也不会破坏解决方案B也使用该项目。您可以将构建设置为每晚自动或从CruiseControl.NET系统托盘应用程序手动触发一个。
答案 4 :(得分：0)
这是另一种选择，但您应该首先认真考虑其他选项。
ProjectA引用了MyLib.dll，恰好是版本1.
调整MyLib项目的输出名称以生成“MyLib.2.dll”。 （你也可以创建一个新项目，但听起来有些过分。）
重建MyLib和ProjectB。 ProjectB现在将引用MyLib.2.dll，使ProjectA和MyLib.dll完全不受影响。
答案 5 :(得分：0)
你的问题非常笼统。你想要达到什么目的？项目A应该使用lib的版本2还是旧版本？
如果A应该使用版本1，那么强命名或私有部署应该可以解决您的问题。但我认为那时你不会问这个问题。
如果A应使用版本2，则解决方案取决于您的更改。如果程序集的接口没有改变（但只有内部算法），那么A应该在不重新编译的情况下使用V2。如果界面已更改，则无论如何都必须调整项目A，并且无法获得通用解决方案。
为了保持所需的更改，可管理的是良好的对象/界面设计问题。但是，如果没有关于对象和所需更改的详细信息，如何做到这一点无法回答。
答案 6 :(得分：0)
我会将所有代码放在像Subversion这样的版本控件中（使用分支和标记）并自动化构建过程。我使用FinalBuilder。
因为你可以控制图书馆，我会推荐release branches pattern。