维护多个项目使用的类库程序集
好的，这是场景。
项目 A 有一个为其开发的类库（我们称之为 MyLib）。 我使用 MyLib 版本 1 发布了项目 A（内部项目）。
我开始开发项目 B，但将 MyLib 扩展到版本 2，包括对现有类型的一些优化。
如果我将 Mylib 2 发布到项目 A 和项目 B，我将不得不重新编译项目 A 以支持类型更改，是否有人对此有经过验证的解决方案？
Okay, so here's the scenario.
Project A has a class library developed for it (lets call it MyLib). I release project A (in house project) with version 1 of MyLib.
I begin development on Project B, but expand MyLib to version 2, including a few optimizations to existing types.
If I release Mylib 2 to both Project A and Project B, I'm going to have to recompile Project A to support type changes, does anyone have solutions to this that are tried and true?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您可以尝试程序集重定向并让项目A加载较新版本的你的图书馆。 这需要您将重定向信息添加到运行应用程序的所有计算机的配置中，但无需重新编译。 您可以在应用程序配置文件或机器级别执行此操作。
该文件的示例来自该文章：
当然，如果您在新版本中破坏了与原始库的兼容性，则这将不起作用。
You can try assembly redirection and have Project A load the newer version of your library. This would require that you add the redirect information to the configuration of all the machines that the application is run on but you wouldn't have to re-compile. You could do this in the application configuration file or at the machine level.
An example from that article of what the file would look like:
Of course, if you broke compatibility with your original library in the new version this isn't going to work.
如果您不喜欢 @Steven 的程序集重定向方向，并且假设您不想重新编译项目 A，则可以将不同版本的 MyLib 私下部署到每个项目。
然后，项目 A 将继续使用版本 1，而项目 B 将使用版本 2。这似乎是您想听到的 - 而且做起来很简单。 将 MyLib dll 放入每个项目的文件夹（或子文件夹）中，每个项目都会自动选择相应的本地版本，或者您可以在 GAC 中对它们进行强命名，并让每个项目选择您编译的特定版本。
这实际上是默认行为，您不需要执行任何复杂的操作即可实现此目的。
If you don't like @Steven's direction of assembly redirection, and assuming you DON'T want to recompile Project A, you can just privately deploy different versions of MyLib to each project.
Project A would then just continue to use version 1, and Project B would use version 2. This seems to be what you are wanting to hear - and it is trivial to do. Either put the MyLib dll in each project's folder (or subfolder) and each project will automatically pick up the respective local version, or you can strongname them in the GAC, and have each project pick up the specific version you compiled against.
This is actually the default behavior, and you don't need to do anything complex to achieve this.
为 MyLib 指定一个 强名称 和 将其安装到 GAC。 GAC 可以具有同一程序集的多个版本。 这需要为 MyLib 的版本 1（而不仅仅是版本 2）指定一个强名称。
项目 A 需要 MyLib 的版本 1，并在 GAC 中找到它。 项目 B 想要 MyLib 的版本 2，并在 GAC 中找到它。 每个人都很高兴，并且您不必在使用它们的程序集的同一目录中保留 30 个不同版本的 MyLib 副本，从而重新创建 DLL 地狱。
我知道 AviD 也提到了 GAC，但它是作为可执行文件的私有副本的替代方案。 我认为应该避免这种情况。
Give MyLib a strong name and install it to the GAC. The GAC can have multiple versions of the same assembly. It would require giving a strong name to version 1 of MyLib (not just version 2).
Project A wants version 1 of MyLib and finds it in the GAC. Project B wants version 2 of MyLib and finds it in the GAC. Everybody is happy, and you don't have to keep 30 copies of different versions of MyLib in the same directories of the assemblies that use them, recreating DLL-hell.
I know that AviD mentioned the GAC as well, but as an alternative to private copies for the executables. I think that should be avoided.
我的建议：持续集成。
使用像 CruiseControl.NET 这样的工具，您可以重建每个项目/解决方案，甚至可以将一个项目/解决方案的输出（.dll）上传到 Source COntrol 以供其他项目使用，每次都运行单元测试，以便您可以检查解决方案 A 中使用的项目中的添加/编辑是否不会破坏也使用该项目的解决方案 B。 您可以将构建设置为每天晚上自动构建，或者从 CruiseControl.NET 系统托盘应用程序手动触发构建。
My suggestion: Continuous Integration.
Using a tool like CruiseControl.NET you could do a rebuild of every project/solution there is, even have the output of one (the .dll) uploaded to Source COntrol to be used by other projects, have unit tests run every time so you can check if additions / edits in a project used in solution A does not break Solution B also using that project. You could set the build to automatic every night or trigger one manually from the CruiseControl.NET systray app.
这是另一个选择，但您应该首先认真考虑其他选择。
ProjectA 引用了 MyLib.dll，它恰好是版本 1。
调整 MyLib 项目的输出名称以生成“MyLib.2.dll”。 （您也可以创建一个新项目，但这听起来有些过头了。）
重建 MyLib 和 ProjectB。 ProjectB 现在将引用 MyLib.2.dll，而 ProjectA 和 MyLib.dll 完全不受影响。
Here's another option, though you should seriously consider the other options first.
ProjectA references MyLib.dll, which happens to be version 1.
Adjust the output name of the MyLib project to produce "MyLib.2.dll". (You could also create a new project, but that sounds like overkill.)
Rebuild MyLib and ProjectB. ProjectB will now reference MyLib.2.dll, leaving ProjectA and MyLib.dll completely unaffected.
你的问题很笼统。 你想达到什么目标？ 项目 A 应该使用 lib 的版本 2 还是旧版本？
如果 A 应使用版本 1，那么强命名或私有部署应该可以解决您的问题。 但我认为你当时就不会问这个问题。
如果 A 应该使用版本 2，那么解决方案取决于您的更改。 如果程序集的接口没有改变（只是内部算法），那么 A 应该可以使用 V2 而无需重新编译。 如果界面变了，无论如何都得调整A项目，没有一个通用的解决方案。
为了使所需的更改保持在较小的范围内并易于管理，这是良好的对象/界面设计的问题。 但是，如果没有有关您的对象和所需更改的详细信息，就无法回答如何做到这一点。
Your question is quite general. What do you want to achive? Should Project A use version 2 of your lib or the old version?
If A should use version 1, then strong naming or privat deployment should solve your problem. But I think then you whould not had asked the question.
If A should use version 2, then the solution depends on your changes. If the interface of the assembly has not changed (but only internals algorithms) then A should work with V2 without recompilation. If the interface has changed, you will have to adjust project A anyway and there cannot be a general solution.
To keep required changes small an managable is a question of good object/interface design. But how to do that cannot be answered without details about your objects and required changes.
我会将所有代码放入 Subversion 之类的版本控制中（使用分支和标签）并自动化构建过程。 我使用 FinalBuilder。
因为您可以控制该库，所以我建议 发布分支模式 。
I would put all of my code in a version control like Subversion ( use of branches and tags ) and automate the build process. I use FinalBuilder.
Because you have control over the library i would recommend release branches pattern .