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