Different solutions/project files for Local vs Build environments作为改进构建过程的一部分，我们目前正在讨论是否应该在CI生产环境中与本地开发环境中分离项目/解决方案文件。 之所以出现这种情况，是因为我们在上一个项目中遇到了参考问题。人们经常会错误地在错误的位置添加对程序集的引用，这意味着它可以在其本地环境下正常工作，但可能会在其他人或构建机器上损坏。 另外，参考路径在csproj.user文件中，这意味着它们必须提交给源代码管理，因此每个人都必须共享这些相同的设置。 因此，我们正在考虑在CI服务器上拥有单独的项目和解决方案，以便在进行构建时，它将使用这些项目，而不是本地开发项目。 它具有明显的缺点，例如维护这些单独的文件的开销以及需要定义和遵循的相关过程，但是它的好处是，我们可以更好地控制生产环境中发生的确切情况。 我无法找到的是关于该主题的任何内容-不能相信我们是唯一可以考虑这个问题的人-因此欢迎所有想法。 我知道这是不合时宜的。但是，我发现处理引用问题的最佳方法是将一个文件夹映射到驱动器号(例如R :)，然后将所有项目构建到该文件夹??中或将输出复制到该文件夹??中。然后所有引用都是R： SomeFile.dll等。这可以解决以下问题：有时引用是通过绝对路径添加的，有时是相对引用的。 (与" HintPath"有关，我真的不记得了) 令人高兴的是，您仍然可以在构建服务器上使用相同的解决方案文件。老实说，这是绝对必须的，因为您将失去在开发机器上构建的内容与在构建服务器上构建的内容相同的确定性。 在我们最大的项目(一个包含许多应用程序的系统)中，我们具有以下结构
所有外部程序集都添加到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 我们已经更改了项目结构(使用SVN外部组件)，现在每个项目都完全独立。也就是说，任何引用都永远不会与项目目录一起使用(例如，如果Project A引用了ASM X，则ASM X存在于ProjectA的子文件夹中) 我怀疑这应该有助于解决我们的一些问题，但是我仍然可以看到对构建项目进行更多控制的一些优势。 我强烈建议不要这样做。 引用路径不仅存储在.user文件中。提示路径存储在项目文件本身中。您永远不必将.user文件检入源代码管理。 让所有开发人员都使用一组(好的，可能是版本控制的)解决方案/项目文件，而其Release配置正是您最终在生产中要构建的。当对某些项目设置进行调整，不进行合并并转入生产阶段时，拥有单独的项目文件将导致混乱。 您也可以检查一下：
http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx 通常，您将以某种形式为您的Production创建Build项目/脚本，因此将另一个Solution文件放在一起不会出现在图片中。 培训每个人如何使用项目引用，并在项目文件结构下创建目录以供外部程序集引用会更容易。这样，每个人都遵循相同的环境。 |
