我的 SAAS 公司有两个 C#.NET 产品，分别称为 Application Alpha 和 Application Beta。它们都引用了一些我们可以称之为 Core 的库。
目前，代码库是单一的，存储在单个 .NET 解决方案的单个 SVN 存储库中，我们正在尝试使其更加模块化/组件化。我们已将两个应用程序和核心库拆分为单独的存储库，但我们现在遇到了以下问题：
Alpha 和 Beta 必须引用 Core，但我们试图避免直接引用代码，因为那样我们实际上又回到了原点：您需要检查并共同定位所有存储库。那么我们应该如何在这些组件之间引用程序集呢？
每个组件都可以有一个目录，其中包含需要引用的其他组件的 DLL，存储在 SVN 中，但这意味着每次更新 Core 以将新的 DLL 推送到 Alpha 和 Beta 时都需要付出额外的努力。
或者我们可以将 DLL 存储在中央 SVN 位置（和/或 GAC 中），但这意味着每次更新 Core 以供其他人提取新的 DLL 时都要付出额外的努力。
我们忽略了第三种选择吗？
我有类似的东西，其中我有 5 个使用我构建的一系列 Web 控件的应用程序。这些控件被编译成一系列用于模块化的 DLL，并且使用它们的应用程序位于不同的服务器上。
我所做的是利用 VS2008 的构建实用程序来执行一个批处理文件，该批处理文件在执行发布构建时将已编译（更新）的 DLL 复制到生产服务器。
您可以通过转到构建到 DLL（或 DLL）中的项目并右键单击该项目并转到属性来执行此操作。然后你转到 BUILD EVENTS 选项卡。在那里您可以看到 Pre-Compile 命令行和 Post-Compile 命令行文本框。
因此，您的发布版本可以完全自动化，您永远不必担心生产 DLL 版本之间的 DLL 地狱般的差异。
希望这会有所帮助，JP
您可以让 Alpha 和 betat 的重建脚本创建工件（即构建核心）并将核心构建的结果放置在引用该位置的特定位置。
您可以使用SVN:externals。它是为这种类型的场景设计的。
如果您想避免这种情况，这些可能是您更好的选择。不过，我会避免将文件放在 GAC 中，除非您的核心项目非常稳定，并且不会经常更改。将 DLL 放在本地提供了更大的灵活性。
每个组件都可以有一个目录，其中包含需要引用的其他组件的 DLL，存储在 SVN 中，但这意味着每次更新 Core 以将新的 DLL 推送到 Alpha 和 Beta 时都要付出额外的努力。
这可以通过良好的构建系统相当容易地处理。这种方法有一些缺点（即：构建系统中的可执行依赖项），但也有一些优点，包括允许每个依赖项目根据需要具有不同的版本等。