经历了,MSBUILD.exe花了很长时间。
此命令使用50+ min执行: C:\Program (x86)\MSBuild\14.0\Bin\amd64>MSBUILD C:\xyz.sln C:\xyz.sln /p:OutDir=c:/test
此命令将执行: C:\Program (x86)\MSBuild\14.0\Bin\amd64>MSBUILD C:\xyz.sln /p:OutDir=c:/test
问题:
1:用/p:Config=Release代替/p:Configuration=Release可以吗?
2:使用/p:Configuration=Release使构建如此之久的根本原因是什么?
发布于 2018-02-09 07:14:15
1:用/p:Config=Release代替/p:Configuration=Release可以吗?
恐怕不是。正如Lex注释一样,/p:Config=Release不是一个有效的参数。我已经用这个参数创建了一个测试示例,但是我发现解决方案是使用默认配置Debug构建的。

因此,参数/p:Config=Release 是无效的.。
使用/p:Configuration=Release使构建如此之久的根本原因是什么?
作为上面的测试,当您使用/p:Config=Release进行构建时,VS/MSBuild将使用默认配置Debug构建解决方案。正如我们所知道的,Debug模式所做的优化要少得多,因为这会使指令和代码行之间的映射变得混乱。因此,编译器在那里做的工作较少。即使一个完整的调试构建速度较慢,debug构建发生的频率也要高得多,并且通常可以比发布版构建can更多地利用增量构建。因此,调试构建通常不需要完成与发行版构建一样多的工作。因此,带有Debug配置的命令将花费更少的构建时间。
此外,当您第一次完成构建解决方案时,您应该清理解决方案,否则,解决方案中的大多数项目将跳过构建。因为他们中的大多数都是最新的。因此,您应该在第一次构建解决方案之后清理该解决方案。
此外,如果您想了解有关构建过程的详细信息,可以将“日志详细性”设置为值诊断,方法是将/v:diag添加到构建命令行:
MSBUILD C:\xyz.sln /p:Configuration=Release /p:OutDir=c:/test /v:diag

https://stackoverflow.com/questions/48697925
复制相似问题