MSBuild - 项目依赖项构建命令异常

我们有一个MSBuild .proj文件，用于构建和运行大量项目。这有文件引用到另一个。由于它是文件引用，因此我们维护解决方案上的Project Dependencies列表，以便MSBuild能够识别执行项目的订单。MSBuild - 项目依赖项构建命令异常

最近我们遇到了问题，我们的美国开发团队为一个项目添加了新的引用，但没有更新依赖项列表。这可以在本地和服务器上为他们构建。然而对于英国团队来说，这个构建对于所有的开发者来说一直都失败

我想明白为什么会出现这种情况。我能想到的唯一情况是，当两个项目基本上排在同一级别时，我们的文化会导致构建顺序略有不同。即如果项目A和项目B被认为具有相同的依赖关系，那么这两个项目所建立的顺序是任意确定的，而这在英国文化与美国文化中可能不同。

这就是说，我的机器（它为我打破了）有地区格式设置英语美国。和位置英国。

这听起来可行吗？还是有更好的解释呢？

来源

2014-02-14 Obsidian Phoenix

更改文化不会解决您在组件输出中制作文件引用而不是构建程序集项目的项目引用的问题。

解决方案文件确实映射依赖关系，并帮助MsBuild确定构建顺序。当MsBuild处理一个解决方案时，它首先将它转换成MsBuild xml格式，然后通过列出依赖项来确定项目的顺序，然后通过比较输入文件的最后更新时间和输出来确定是否需要重建项目文件。

在项目中有项目引用时（在项目中，打开References文件夹，删除对输出程序集的引用，而是引用项目本身）。这将修改项目文件，用ProjectReference项目组替换参考项目组。这允许MsBuild在项目级别上做出此决定并解决必须手动配置项目构建顺序的问题。

来源

2014-02-14 13:44:29 Nicodemeus

不幸的是，由于各种原因，我们的解决方案通常不使用项目引用。我们有数百个项目，通常使用不同的解决方案打开Soln - 这些解决方案之一的项目使用项目引用，但部分之间的引用使用文件引用。 –

因此，如果项目A依赖于项目B的输出，但使用文件引用而不是项目引用，则在编译时您不知道是否有来自项目B的最新代码。这只是你可以添加的一些管道，让你的生活更轻松。过去，我必须在包含> 100个项目的解决方案上进行此项工作。它看起来像是一项艰巨的任务，但通过不再拘泥于错误的范例将为您节省很多的难处:) – Nicodemeus

我们的构建被配置为在每个构建中擦拭干净并从头开始，所以这不是主要关心的问题。我很乐意改用渐进方式，但我相信公司在过去一直受到困扰，因此希望保持完整的清洁版本。我相信切换到文件引用是因为我们使用更小的更集中的解决方案进行开发 - 项目引用喜欢在您将它们从解决方案中删除时尝试删除自己。 –

MSBuild - 项目依赖项构建命令异常

回答

相关问题