作为改进构建过程的一部分，我们目前正在讨论是否应该在CI生产环境中与本地开发环境中分离项目/解决方案文件。

之所以出现这种情况，是因为我们在上一个项目中遇到了参考问题。人们经常会错误地在错误的位置添加对程序集的引用，这意味着它可以在其本地环境下正常工作，但可能会在其他人或者构建机器上损坏。

另外，参考路径在csproj.user文件中，这意味着它们必须提交给源代码管理，因此每个人都必须共享这些相同的设置。

因此，我们正在考虑在CI服务器上拥有单独的项目和解决方案，以便在进行构建时，它将使用这些项目，而不是本地开发项目。

它具有明显的缺点，例如维护这些单独文件的开销以及需要定义和遵循的相关过程，但是它的好处是，我们可以更好地控制生产环境中发生的确切情况。

我无法找到的是关于该主题的任何内容，无法相信我们是唯一考虑此问题的人，因此欢迎所有想法。

解决方案

回答

通常，我们将以某种形式为Production创建Build项目/脚本，因此将另一个Solution文件放在一起不会出现在图片中。

培训每个人都可以使用项目引用，并在项目文件结构下为外部程序集引用创建目录会更容易。这样，每个人都遵循相同的环境。

回答

我强烈建议不要这样做。

• 引用路径不仅存储在.user文件中。提示路径存储在项目文件本身中。我们永远不必将.user文件检入源代码管理。
• 让所有开发人员都使用一组(好的，可能是版本控制的)解决方案/项目文件，而其Release配置正是我们最终在生产中要构建的文件。当对某些项目设置进行调整，不进行合并并转入生产阶段时，拥有单独的项目文件将导致混乱。

我们也可以检查一下：

http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx
http://bytes.com/forum/thread268546.html

回答

我们更改了项目结构(使用SVN外部组件)，现在每个项目都完全独立。也就是说，任何引用都永远不会与项目目录一起使用(例如，如果Project A引用了ASM X，则ASM X存在于ProjectA的子文件夹中)

我怀疑这应该有助于解决我们的一些问题，但是我仍然可以看到对构建项目进行更多控制的一些优势。

回答

在我们最大的项目(一个包含许多应用程序的系统)中，我们具有以下结构

/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文件夹位于服务器上，因此我们确保开发人员计算机和构建服务器具有相同的开发布局。

回答

@David信不信由你，这就是我们现在真正拥有的东西，但它仍然给我们带来了麻烦！

但是，我们正在进行一些更改，这些更改由于迁移到TeamCity和多个构建代理而被迫执行，因此我们无法在当前项目之外引用目录，正如我在上一个答案中提到的那样。

查看此链接的"外部"部分，以了解我的意思http://www.dummzeuch.de/delphi/subversion/english.html

回答

我知道这是不合时宜的。但是，我发现处理引用问题的最佳方法是将一个文件夹映射到驱动器号(例如R :)，然后将所有项目都构建到该文件夹​​中或者将输出复制到该文件夹​​中。然后所有引用都是R：\ SomeFile.dll等。这可以解决以下问题：有时引用是通过绝对路径添加的，有时它们是相对添加的。 (与" HintPath"有关，我真的不记得了)

令人高兴的是，我们仍然可以在构建服务器上使用相同的解决方案文件。说实话，这是绝对必须的，因为我们将失去在开发机器上构建的内容与在构建服务器上构建的内容相同的确定性。