【问题标题】:CoreCompile is skipped. I want it to be happenedCoreCompile 被跳过。我希望它发生
【发布时间】:2017-06-06 20:46:25
【问题描述】:

我的情况是,我有一组源代码受控的 c# 文件。我下载它,我在命令行中使用此命令构建解决方案文件。

"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" MyProj.sln /property:Platform=x64

但是当我这样做时,CoreCompile 会被跳过,说“跳过目标“CoreCompile”,因为所有输出文件相对于输入文件都是最新的。”问题是,它生成的 dll 不包含 .cs 文件中的许多更改。

当我在 .cs 文件中做一个小改动(例如,放置一个日志)时,它构建得很好,并且生成的 dll 包含所有更改。

但是,构建 32 位版本时没有跳过 CoreCompile 第一次本身。 (相同的命令,但带有/property:Platform=x86

我无法理解这种行为。请帮忙。谢谢。

【问题讨论】:

  • 请注意,.net 框架中包含的 msbuild 版本(版本 4.*)相当旧。新版本是 VS 的一部分,也可以使用 Build Tools 安装程序获得

标签: c# msbuild


【解决方案1】:

MSBuild 能够build incrementally。它通过检测每个目标之间的输入文件更改和丢失的输出文件来实现这一点。如果您更新存储库并且没有对.cs 文件进行更改,则应该跳过CoreCompile。您可以查找最新的 roslyn 版本 here 的输入和输出。

您可以使用/t:Rebuild(与"/t:Clean;Build" 相同)强制进行干净的构建。

另请注意,更改通过/p:name=value 传入的参数通常不会影响构建。增量构建逻辑基于文件更改,而不是值。如果影响输出目录的参数发生更改,则认为输出丢失。如果只有影响某些编译设置的参数更改,它可能会触发增量构建目标。此类设置通常在项目中设置,这将导致对$(MSBuildAllProjects) 的更改,这通常是增量目标的输入。

例如在 .NET Core there was a problem 中设置 /p:Version=1.2.3/p:VersionSuffix=beta1 时不会影响增量构建。

【讨论】:

  • 嘿马丁,/t:Rebuild 在我的情况下有效。但是,32 位构建的 CoreCompile 完成但 64 位构建的奇怪行为可能是什么原因?
  • 编辑了答案:看起来Platform 在通过命令行传递时不一定会更改 CoreCompile 的输入。我链接了一个我最近处理的增量构建问题的 GitHub 问题,它遇到了类似的问题(命令行参数不影响构建),这可能是一个有趣的阅读。
  • 谢谢马丁。但是,我仍然无法理解这种行为。 /t:Rebuild/t:Clean;Build 从第二次开始工作。第一次执行时,它只是说“跳过 CoreCompil.......”。但是这两次执行之间没有任何变化。有没有办法让它在第一次发生?由于我们的构建过程只执行一次这个命令。
  • 所以即使与/t:Rebuild 一起使用,CoreCompile 也会从存储库的“新克隆”中跳过?这听起来不对。您需要在某处发布 csproj 文件以获取 repo。还要使用 VS / Build 工具中包含的 msbuild 版本。版本“4”大约有 7 年历史。
  • 嘿兄弟..问题解决了。我也将输出 bin 文件夹 (\bin\debug\x64*) 放入存储库。因此,较新的文件不是在构建过程中构建的(使用 msbuild)。当我从存储库中删除文件夹时,开始工作。谢谢你的信息马丁。 :)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-01-30
相关资源
最近更新 更多