使用MSBuild任务在同一解决方案中构建另一个（C++）项目？

Du对于我现在还不能破解的奇怪依赖链，我想在同一解决方案中将另一个C++项目构建为一个“后期构建”步骤。使用MSBuild任务在同一解决方案中构建另一个（C++）项目？

我知道如何调用的MSBuild在命令行上，但我想它可能会更有意义使用内置MSBuild任务只是触发其他项目的构建：

my.vcxproj：

<?xml version="1.0" encoding="utf-8"?> 
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
... 
    <Target Name="BuildTheOtherProject" AfterTargets="Build"> 
     <MSBuild Projects="..\theother\theother.vcxproj" Targets="Build" Properties="Configuration=$(Configuration);Platform=$(Platform)"> 
     </MSBuild> 
    </Target> 
</Project>

这似乎工作得很好乍一看，但这会继续工作（想想：并行项目建设的完整解决方案等），我是否将正确的值传递给MSBuild任务？

有一个related question询问有关C＃项目的同样的事情，似乎有一个csc的问题（这与vcxproj无关），所以我想知道一般的立场是什么？

（我在Visual Studio的2015年大气压）

来源

2017-10-20 Martin Ba

你是什么意思“我想知道一般的立场是什么”？你不能成功建立另一个项目？我测试了您的代码片段，并且它已成功构建。 –

是您正确调用MSBuild任务。但你不应该这样做。这是不好的风格。而且你一定会在将来使用这个隐藏在.vcxproj文件中的小技巧绊倒某人。以正确的方式指定依赖项：在解决方案文件（.sln）中，Visual Studio将确保文件按照正确的顺序构建。如果您需要更多功能，则可以使用<ProjectReference>来指定依赖项，而不是使用解决方案文件，但这是一个不同的主题。

在我拥有非常庞大的代码基础的公司工作的所有年中：这样的技巧从未做过，也从不应该这样做。

来源

2017-10-25 12:36:35

事实上：起初它似乎很好地工作，只是打破了完整的构建运行，因为MSBuild实际上检测到循环依赖，我想要解决这个问题。所以在我的情况下，它毕竟没有工作，并且应该完成一个“ProjectReference”（目前还不能）。我鄙视解决方案的依赖关系，如果软件项目包含多个解决方案，那么他们很难维持。去参考'ProjectReference' - 但首先我需要在这里清理项目结构。 –

Btw .:您是否考虑在vcxproj中使用MSBuild任务“hack”，或者只有在“ProjectReference”应该工作时才使用？ –

嗨。我会考虑在.vcxproj中随时使用MSBuild任务。比咬伤子弹和使用解决方案依赖性更糟糕。与解决方案（* .sln）一样糟糕，它们比这更好。 –

使用MSBuild任务在同一解决方案中构建另一个（C++）项目？

回答

相关问题