.NET Core和.NET Standard项目不支持增量构建。

Question

我在我的桌面解决方案中使用了.NET标准库，这样我就可以在我的桌面和Web解决方案之间共享这些库。然而，我现在遇到了增量构建问题。有没有人也遇到过这个问题并设法解决？

我可以看到.NET标准库具有一些增量构建功能。例如，如果我在命令行上使用“dotnet build”构建它们，则需要1秒钟，如果我在该库中进行代码更改并再次运行，则需要2秒钟。如果我第三次运行，则回到1秒。

但是，在纯.NET Framework应用程序（例如控制台应用程序或wpf应用程序）中，传统上，如果您没有进行代码更改，那么在Visual Studio中它甚至不会尝试构建该项目。它只是说“1 up-to-date”。我发现.NET标准库始终重新复制到输出目录，并且每次都会导致整个WPF项目重新构建。随着时间的推移，如果每个代码更改都需要5秒钟来构建，这将开始变得很烦人！

- Laurence Bargery

---

不需要复制/分发随框架提供的.NET库。 - T.S.

可能是《C#编译/构建是否为增量过程？》的重复问题。 - Paul Sweatte

这不是重复的问题。首先，C#编译/构建是一个误称。这实际上是一个MSBuild问题。其次，这个问题特定于.NET Core和.NET Standard，在VS 2015中没有Visual Studio支持，这可能是该问题所涉及的最新版本。 - Void Star

Answer 1

我至少能为您提供部分答案。关于二进制文件每次都复制的问题，微软解释说基本上是因为没有支持，需要更新到更高版本的目标框架。

目前我们不会对工具中附带的兼容性 shims 进行智能修剪，因此最终会将它们全部复制出来。如果您（或您的依赖项）不依赖它们，则可以安全地删除/不部署它们，但盲目操作可能会破坏某些依赖项。

这个问题应该在4.7.1中得到解决。

值得一提的是，使用.NET Framework 4.7.1及以上版本时，您将无需部署任何额外的文件以支持.NET Standard。今天，如果您的目标是Xamarin或.NET Core，那已经是这种情况了。

至于为什么它总是复制文件，而不像它应该那样有选择性地进行，我不确定。我已经搜寻了构建日志，我相信这些文件没有被正确地添加到构建目标的输出列表中，但很难诊断。Visual Studio还有智能方法完全避免调用MSBuild，所以在MSBuild脚本中跳过目标的逻辑甚至都不必运行。Visual Studio大部分都是黑盒子，但根据你和我观察到的行为，我怀疑这个逻辑也是错误的。

这是一个令人沮丧的问题，因为仍然有理由针对旧版本的.NET Framework，例如如果库被分发给可能使用Visual Studio 2013进行构建并且不能期望更新的客户。

- Void Star