Solution with 56 projects is unsable once migrated to csproj.

dotnet / project-system

The .NET Project System for Visual Studio

MIT License

969 stars 389 forks source link

Solution with 56 projects is unsable once migrated to csproj. #1384

Closed NTaylorMullen closed 7 years ago

NTaylorMullen commented 7 years ago

Every major operation (opening/restoring, building, etc.) takes several minutes to complete, usually resulting in the "not responding" dialog over and over. As a disclaimer the project does take more time than average project to restore but it should not repeatedly dive into the "not responding" state or take as long as it currently does. Doing these operations at the command line is significantly faster.

This branch of MVC demonstrates the issue quite well. Note, it used to work decently fine with the xproj system.

The VS I'm using:

NTaylorMullen commented 7 years ago

Pinging this thread. Any ETA on a usable VS for MVC?

mavasani commented 7 years ago

Update: The Test Window fix has been checked in today, and the next D15Rel build should have this fix. I'll verify this tomorrow and post an update.

davkean commented 7 years ago

@NTaylorMullen We understand what the SkipCompilerExecution issue is (it's a bug in MSBuild). The workaround is to not use command-line restore when VS is open.

mavasani commented 7 years ago

I verified that the Test Window UI delay does not repro in build D15Rel 26223.1

mavasani commented 7 years ago

@NTaylorMullen at this point, let us use separate issues to track any functional issues - #1554 and https://github.com/Microsoft/msbuild/issues/1726 are tracking SkipCompilerExecution errors.

If you still see performance problems on MVC solution, please re-activate this issue and let us know as soon as possible.