在 .NET 解决方案之间共享公共库的最佳实践
我们拥有 MSVS 解决方案池（解决方案“A”、“B”、“C”...），它们共享名为“Common.dll”的程序集的基本功能。
有 3-5 个主动解决方案（正在开发中），而其他解决方案是被动的，几乎不会重建。
Common.dll 始终处于开发中。如何保留我的解决方案代码有多种选择，您会建议什么以及为什么？
一个）。 将 common.dll 源代码放入每个解决方案。优点：它将帮助主动解决方案与 common.dll 并行发展，而被动解决方案将是可编译的。缺点：很难在活动解决方案之间同步活动的 common.dll 代码
B)。 将 common.dll 二进制代码放入每个解决方案。优点：所有项目都可以编译，而 common.dll 代码将集中。缺点：很难与 common.dll C) 并行开发主动解决方案
。 将每个项目引用到最后的 common.dll 二进制文件 看起来像 B。但如果 common.dll 会增长并改变其接口，那么被动解决方案就会带来问题（有些人可能会说接口应该始终保持不变）
D ）。 ？
先感谢您！
We have pool of MSVS solutions (Solution "A", "B", "C", ... ) that share basic functionality in assembly called "Common.dll".
There are 3-5 active solutions (that are under developing) while others are passive and hardly ever be rebuilt.
Common.dll is always under developing. There are several options how to keep my solutions code, what will you suggest and why?
A). Put common.dll source code to every solution. Pros: it will help active solutions to grow with common.dll side-by-side while passive solutions will be compilable. Cons: it's hard to synchronize active common.dll code between active solutions
B). Put common.dll binary code to every solution. Pros: all projects will be compilable while common.dll code will be centralized. Cons: it's hard to grow active solutions side-by-side with common.dll
C). Reference every project to last common.dll binaries looks like B. but it'll bring problems with passive solutions if common.dll will grow and change it's interfaces (some may say interfaces should always stay constant)
D). ?
Thank you in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
还有其他选项：
D) 将所有项目放在同一个 SVN（或其他 CVS）根目录中。
这允许分支和标记，同时确保每个项目都有一致的 Common 分支版本。这样，您只需根据需要将项目包含在每个解决方案中即可。
当然，问题是所有项目都在同一个 SVN 中。 :)
这样做的好处是，您一定会在创建的每个分支中获得 Common.dll 源代码的快照。
E) 使用 SVN 外部
如果您使用 Subversion，则可以使用 SVN 外部（将本地子文件夹映射到版本化资源的 URL）。 GIT 也支持类似的东西，但是如果您想将更改提交到外部存储库，那就有点复杂了。
There are other options, also:
D) Put all projects inside the same SVN (or other CVS) root.
This allows branching and tagging while making sure you have a consistent version of Common branched with every project. This way you simply include the project in each solution as needed.
The problem is, of course, that all projects are inside the same SVN. :)
What's good about it is that you are sure to get a snapshot of your Common.dll's source code in every branch you create.
E) Use SVN Externals
If you're using Subversion, you can use SVN Externals (mapping a local subfolder to a url of a versioned resource). GIT supports something similar too, but it's a bit complicated if you want to submit changes to the external repos.
我们的实践主要类似于 B。CI
服务器确保公共库始终是最新的（即使它们自己使用其他公共库）。每个使用公共库的解决方案都有一个“Lib”文件夹，我们在其中放置构建工件，但这些工件不受源代码控制（与外部工件相反，例如通过 NuGet 导入的工件）。
因此，在开发时，您不会因为公共库中的重大更改而遇到问题，并且开发人员会选择升级的时间点（但他总是必须在提交到中央存储库之前这样做）。
CI服务器总是会将最新的公共库复制到正在构建的解决方案的“Lib”中，以便集成最新的公共库。如果我们需要使用旧库创建构建（特定的修补程序版本 - 非常罕见），我们始终可以使用具有匹配日期的构建工件。不过，正常的补丁/修复版本通常也会升级到最新的公共库。
We practice something mostly like B.
A CI server makes sure that the common libraries are always up-to-date (even if they use other common libraries themselfes). Each solution which uses common libraries has a "Lib" folder where we put the build artefacts, but these are not under source control (in contrast to external artefacts, such as the ones imported though NuGet).
So while developing you don't get problems because of breaking changes in the common libs and the developer chooses the point in time when he upgrades (but he always has to do that before he commits to the central repo).
The CI server will always copy the latest common libraries into the "Lib" of the solution under build, so that the latest common libraries are integrated. If we need to create a build with old libraries (specific hotfix release - very rare), we can always use the build artefacts with the matching date. Normal patch/fix releases are usually also upgraded to the latest common libraries though.
我会立即说折扣（A），因为您将杀死您拥有的可维护性的任何能力！
实际上，这确实取决于这些代码库更改的频率。
我正在处理的类似设置的当前解决方案是拥有一个单独的“Common”项目，并将二进制文件复制到引用 Common 项目的每个项目的“Libs”文件夹中。原因是我们能够将 common.dll 的显式版本部署到每个项目。 Libs 文件夹通过 TFS 维护。因此，虽然父项目不需要重新编译，但 TFS 将看到新的签入并可以采取相应的行动。
我考虑的另一个选择是根据 此链接。但请注意，这限制了您引用不同版本的通用版本的能力，除非您为每个物理版本创建单独的项目版本，但由于可维护性，这种情况不太可能且不可取。
I'd say discount (A) straight away, as you will kill any capability you have for maintainability!
Effectively, it does come down to how often these code bases will change.
Our curent solution on a similar setup I'm working on is to have a seperate 'Common' project, and the binaries are copied to the 'Libs' folder for each Project that references the Common one. The reason for this is that we then have the capability to deploy explicit versions of common.dll to each project. The Libs folder is maintained via TFS. So whilst the parent project does not need to be recompiled, TFS will see a new check in and can act accordingly.
Your other option which I'd consider is to reference the common project 'in situ' as per one of the solutions at this link. Note though that this limits your ability to reference different versions of common unless you are creating seperate project versions for each physical version, which would be unlikely and unadvisable, again due to maintainability.