作为我们构建过程改进的一部分，我们目前正在讨论是否应该在我们的 CI 生产环境和本地开发环境中拥有单独的项目/解决方案文件。
出现这种情况的原因是我们在之前的项目中遇到的参考问题。人们经常会错误地将对程序集的引用添加到错误的位置，这意味着它可以在他们的本地环境中正常工作，但可能会在其他人或构建机器上中断。
此外，引用路径位于 csproj.user 文件中，这意味着这些文件必须提交到源代码管理，因此每个人都必须共享这些相同的设置。
所以我们正在考虑在我们的 CI 服务器上拥有单独的项目和解决方案，这样当我们进行构建时，它会使用这些项目而不是本地开发项目。
它有明显的缺点，例如维护这些单独的文件和需要定义和遵循的相关流程的开销，但它的好处是我们可以更好地控制生产环境中发生的事情。
我无法找到有关此主题的任何内容-无法相信我们是唯一考虑此问题的人-因此欢迎所有想法。
在我们最大的项目（由许多应用程序组成的系统）中，我们具有以下结构
/3rdPartyAssemblies
/App1
/App2
/App3
/.....
所有外部程序集都添加到 3rdPartyAssemblies/Vendor/Version/...
我们有一个 CoreBuild.sln 文件，它充当所有共享程序集的 MSBuild 脚本，以确保按依赖顺序构建（即，确保 App1.Interfaces 在 App2 之前构建，因为 App2 具有对 App1.Interfaces 的引用）。
所有应用程序间引用都以 /bin 文件夹为目标（我们不使用 bin/debug 和 bin/release，只使用 bin，这样引用保持不变，我们只是根据构建目标更改发布配置）。
Cruise Control 在构建任何其他应用程序之前为任何依赖项构建核心解决方案，并且由于服务器上存在 3rdPartAssemblies 文件夹，我们确保开发人员机器和构建服务器具有相同的开发布局。
我知道这是不合时宜的。但是我发现处理引用问题的唯一最佳方法是将文件夹映射到驱动器号，例如 R: 然后所有项目都构建到该文件夹中或将输出复制到该文件夹中。然后所有引用都是 R:\SomeFile.dll 等。这可以解决有时引用是通过绝对路径添加的问题，有时它们是相对添加的。（我不记得与“HintPath”有关）
那么好的事情是，您仍然可以在构建服务器上使用相同的解决方案文件。老实说，这是绝对必须的，因为您无法确定在开发机器上构建的内容与在构建服务器上构建的内容相同。
我们已经改变了我们的项目结构（利用 SVN Externals），现在每个项目都是完全独立的。也就是说，任何引用都不会超出项目目录（例如，如果项目 A 引用 ASM X，则 ASM X 存在于 ProjectA 的子文件夹中）
我怀疑这应该有助于解决我们的一些问题，但我仍然可以看到对构建项目进行更多控制的一些优势。
@David - 信不信由你，这就是我们现在真正拥有的，但它仍然给我们带来了问题！
不过，我们正在进行一些更改，这是由于迁移到 TeamCity 和多个构建代理而被迫进行的 - 所以我们不能引用当前项目之外的目录，正如我在之前的回答中提到的那样。
查看此链接的外部部分以了解我的意思 - http://www.dummzeuch.de/delphi/subversion/english.html
我强烈建议不要这样做。
引用路径不仅存储在 .user 文件中。提示路径存储在项目文件本身中。您永远不必将 .user 文件签入源代码管理。
让所有开发人员都使用一组（好吧，可能是版本化的）解决方案/项目文件，其发布配置是您最终在生产中构建的。当某些项目设置被调整，没有被传递并滑入生产时，拥有单独的项目文件会导致混乱。
你也可以看看这个：
http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx http://bytes.com/forum/thread268546.html
通常，您会以某种形式为您的产品创建构建项目/脚本，因此将另一个解决方案文件放在一起不会出现在图片中。
培训大家使用项目引用会更容易，并在项目文件结构下为外部程序集引用创建一个目录。这样每个人都遵循相同的环境。