.net 维护多个项目使用的类库程序集

好的，下面是场景

项目A有一个为其开发的类库（我们称之为MyLib）。我发布了带有MyLib版本1的项目A（内部项目）

我开始开发项目B，但将MyLib扩展到版本2，包括对现有类型的一些优化

如果我同时向项目A和项目B发布Mylib 2，我将不得不重新编译项目A以支持类型更改，是否有人对此有经过验证的解决方案？

您可以尝试让项目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>

---

当然，如果在新版本中破坏了与原始库的兼容性，那么这将不起作用

如果您不喜欢@Steven的程序集重定向方向，并且假设您不想重新编译项目A，您可以私下为每个项目部署不同版本的MyLib。
然后项目A将继续使用版本1，项目B将使用版本2。这似乎是你想要听到的——而且做起来很琐碎。将MyLib dll放在每个项目的文件夹（或子文件夹）中，每个项目将自动获取各自的本地版本，或者您可以在GAC中对其进行strong命名，并让每个项目获取您编译所依据的特定版本。
这实际上是默认行为，您不需要做任何复杂的事情来实现这一点

给Myliba和。GAC可以有同一程序集的多个版本。这需要为MyLib的版本1（而不仅仅是版本2）提供一个强名称

项目A想要MyLib的版本1，并在GAC中找到它。项目B需要MyLib的第2版，并在GAC中找到它。每个人都很高兴，而且您不必在使用MyLib的程序集的相同目录中保留30个不同版本的MyLib副本，从而重新创建DLL地狱

---

我知道AviD也提到了GAC，但作为可执行文件私有副本的替代品。我认为应该避免。

< P>这是另一个选择，尽管你应该首先认真考虑其他选项。

ProjectA引用的MyLib.dll恰好是版本1

调整MyLib项目的输出名称以生成“MyLib.2.dll”。（您也可以创建一个新项目，但这听起来有些过分。）

---

重建MyLib和ProjectB。ProjectB现在将引用MyLib.2.dll，使ProjectA和MyLib.dll完全不受影响。

我的建议：持续集成

---

使用CruiseControl.NET之类的工具，您可以重建存在的每个项目/解决方案，甚至可以将其中一个项目/解决方案（即.dll）的输出上载到源代码管理以供其他项目使用，每次都要运行单元测试，这样您就可以检查解决方案a中使用的项目中的添加/编辑是否也会破坏使用该项目的解决方案B。您可以将构建设置为每晚自动，也可以从CruiseControl.NET systray应用程序手动触发构建。

您的问题相当笼统。你想得到什么？项目应该使用lib的版本2还是旧版本

如果A应该使用版本1，那么强命名或privat部署应该可以解决您的问题。但我想你不会问这个问题的

如果A应该使用版本2，那么解决方案取决于您的更改。如果程序集的接口没有改变（只改变了内部算法），那么A应该在不重新编译的情况下使用V2。如果接口已更改，您将不得不调整项目A，并且无法找到通用解决方案

---

要使所需的更改保持较小的可管理性，需要良好的对象/接口设计。但是，如果没有关于对象和所需更改的详细信息，就无法回答如何做到这一点。

我会将我的所有代码放在Subversion（使用分支和标记）之类的版本控制中，并自动化构建过程。我用

---

因为您可以控制我推荐的库。

尽管GAC通常是一个很好的解决方案，但最佳做法是除非您有充分的理由，否则不要将您的助手放在GAC中。虽然这种情况（通常是版本控制）可能是足够的理由这样做，但在任何情况下都强烈地考虑其他。我只是认为微观管理每个文件夹中的库版本会增加失败点。如果内部安装的数量不多，或者使用库的应用程序数量不多，本地副本将不是我的首选。@Joel同意，这取决于共享的范围。我在以前的一家公司使用了绑定重定向。不得不说，有很好的和易于使用的，虽然你显然得到了大量的修订。其中一个有用的特性是它很容易提供更新机制，也可以通过删除旧的重定向来回滚。这是对我最有用的回应。