.NET Core和.NET Standard项目不进行增量构建

Question

I'm using .NET standard libraries inside my desktop solution so I can share those libraries between my desktop and web solution. However, I'm seeing incremental build problems now. Has anyone else experienced this or managed to fix it?

I can see that the .NET standard libraries have some incremental build features in that if I build them on the command line using "dotnet build" it takes, for example, 1 second and then if I make a code change in that library and run again it takes 2 seconds. This goes back to 1 second if I run for a third time.

However, in pure .NET framework applications like a console app or wpf app, traditionally if you make no code change then inside visual studio it doesn't even attempt to build the project. It simply says "1 up-to-date". I'm seeing the .NET standard libraries always re-copied to the output directory and they also cause my entire WPF project to rebuild every time. After a while this starts to get annoying if every code change takes 5 seconds to build!

Answer 1

I have at least a partial answer for you. The issue of the binaries copying out every time is explained by Microsoft as essentially there is no support, update to a later target framework version .

At this point we don't do any smart trimming of the compat shims that come with the tooling so it ends up copying them all. If you (or your dependencies) don't rely on them it is safe to delete/not-deploy them but doing it blindly may break some of your dependencies.

And this is supposed to be fixed in 4.7.1

It's worth mentioning that with .NET Framework 4.7.1 and up you'll not have to deploy any extra files for .NET Standard. Today, that's already the case if you target Xamarin or .NET Core.

As for why it always copies, instead of doing so selectively as it should, I am unsure. I have scoured build logs and I believe that the files have not been properly added to the output list of a build target but it is difficult to diagnose. Visual Studio also has smart ways to entirely avoid invoking MSBuild, so logic in the MSBuild script to skip a target doesn't even have to run. Visual Studio is mostly a black box, but I suspect this logic is broken too, based on the behavior both you and I have observed.

This is a frustrating issue because there are still good reasons to target old versions of .NET Framework, for example if a library is distributed to a customer who may build against it using Visual Studio 2013, and cannot be expected to update.