Slow build with msbuild and dotnet cli

Ok so we migrated over a few weeks ago but I’m really getting annoyed by the lack of incremental build on rc4. Debug times take 13 seconds from f5 to debugger start because dotnet build lacks any and all smarts to see that only the top level project changed so it just rebuilds all projects again.

I don’t have any experience with msbuild and I’d expect at least this to just work out of the box. It’s even not working for the simplest case

• dotnet new mvc
• dotnet restore
• dotnet build first time builds nicely
• dotnet build changed nothing, starts all over again wasting 3 seconds of my time.

.NET Command Line Tools (1.0.0-rc4-004849)

Product Information:
 Version:            1.0.0-rc4-004849
 Commit SHA-1 hash:  7dcefb5076

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.0-rc4-004849

[tetious]

I’m seeing build times over a minute, where previously (project.json) I saw 20ish seconds worst case. A full build of my not-very-large at all project with ZERO changes takes nearly 20 seconds now. So that’s all overhead, and poking around it seems to all be due to ResolveAssemblyReferences/ResolveProjectReferences.

I think this is the sort of thing that can permanently hurt .net core’s reputation. I don’t understand why it was acceptable to replace project.json when important regressions like this are present.

The decision to switch away from the new project format, which had numerous advantages, was already a contentious one. The argument I heard was frequently that it was just XML vs json, and it wasn’t a huge deal.

It seems that in reality that much like when DNX went away, cross-platform developers have lost a lot and gained nothing with the shift back to csproj. If cross-platform (i.e. not using Visual Studio) development truly is important to MS, I think they need to consider the impact of these sorts of regressions more carefully, and with more weight.

In my opinion, the compile/run/test cycle is one of the most important to get right for developer happiness and productivity. Microsoft doesn’t seem to agree, when you consider deeds vs words.

[davkean]

@jeffhube and folks - performance is very top of mind at the moment, and we’re actively working on it, we’ve got https://github.com/dotnet/project-system/issues/2789 which we’re using as the uber issue.

We’re first focusing on evaluation/target performance - which affects all builds, then we’ll peel off and start digging into individual scenarios such as command-line and VS performance - which will be approached differently due to the way they do builds.