VisualStudio takes too long at design time.

[Clockwork-Muse]

Way, way, waaaayyyy too long.
For some reason I don't understand, commit 5c2c440 is the latest point in history where I can open projects in VisualStudio in a reasonable time frame. And I don't mean 30s-1minute like I've seen some people muttering about; my times are well over 10 minutes, on at least two projects (System.Linq.Parallel and System.Net.Sockets).

Strangely, I've never opened or built the project referenced in the subsequent commit (System.Net.Mime), and I'm on Windows, too (aa3bea0 just adds test rids for Linux derivatives).

Can work around easily enough.

[hughbe]

I've found this as well - corefx projects seem to be hanging. I went as far as uninstalling VS to try to fix it, no luck.
Btw, dotnet/buildtools#951 should help fix the mutterings about long(ish) design time builds doing too much before (I.e 30s-1min)

[karelz]

@ericstj any idea why would your commit 5c2c440 introduce that?

[ericstj]

That commit has already been undone: it was only a temporary workaround. It did introduce some project references (which would hurt perf, but only slightly and only for the projects I touched) but those have since been removed.

One thing comes to mind, we've had a couple package updates lately: if you aren't running sync or build after picking up those updates you could be triggering a restore in the background build of VS and downloading new package sets. /cc @weshaggard

[ericstj]

I'm pulling in @hughbe's design time fix with dotnet/corefx#12009, I'm also going to make some restore workarounds to buildtools because I suspect that design time build is running restore.

[Clockwork-Muse]

No, 5c2c440 is a "good" commit for me. It's the one(s) after that cause me problems.
The process was taking 15+ minutes opening System.Linq.Parallel, even after running sync (which takes 40 minutes for me) or build (at least via build-native -project=src/system.linq.parallel/system.linq.parallel.sln).
On 5c2c440, opening projects which I haven't previously built do run a bit longer, but still within a minute or so, and it's faster after that. For aa3bea0 and later commits, it never seems to cache or anything.

[steveharter]

+1 on the slow project loading. 15 minutes or so to open projects with high CPU utilization. Opening "old" projects from an old branch from a week or so ago open fast, indicating something in the design-time build commands.

[stephentoub]

I have the same problem. Even after doing a full clean and a full sync, it takes a very long time to open projects. Same for making changes to a project in the IDE, e.g. adding a new file can take minutes.

[ericstj]

We got to the bottom of it (thanks @danmosemsft, @alexperovich, & @weshaggard).

It turns out that design time build evaluates all items regardless of conditions, and @weshaggard added an item that, when it's condition is false, will cause MSBuild to glob the entire enlistment drive (eg: C:). dotnet/corefx@760104f

@weshaggard is picking this up to fix it.

[weshaggard]

PR dotnet/corefx#12020 should tackle this issue.