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