In this post I’m going to look at ways to decrease load and build times for large solutions (400+ projects) in Visual Studio 2017.

Here at work we have a solution that is 392 projects.

That is bigger than all the solutions I have worked with in the past.

The problem working with a solution of this size is usually two fold:

1. Load time of the solution
2. Build time of the code

If these times are measured in minutes (or even tens of minutes) you can probably do a lot better.

Ok lets explore your options.

1. The solution load time

So what can we try out to get the load time down?

Your personal solution file?

One way to decrease the load time drastically, is to create your own solution file that contains only parts of the system you are working on.

But that has it’s own sets of problems:

• you will need to add projects to your solution when somebody else adds/removes them.
• .sln file is usually outside of source control.
  • you could of course litter your source control with multiple .sln files from all the devs (ever) but I wouldn’t.
• build configurations (see below) can’t be shared between developers (since the .sln file is not in source control or they are using their own)

So what can you do?

First of all you should update to VS 2017 V 15.6. That version came with a 2x faster load speeds for large solutions.

This will even get better with version 15.7 Preview 4 where

“In this release, we’ve improved solution load time for C# and VB projects by an average of 20%.”

Since I don’t have a version of VS older than 15.6 on my computer I can’t measure the time decrease in the solution load. But what I can do is to measure how long it takes using the latest version. Lets take a look.

“Load-up testing” my solution

My setup

• Visual Studio 15.6.5 (where I have quite few extensions installed so the load time could maybe be faster).
• I first opened my solution and opened up 1 .cs file and then closed Visual Studio.

This way I could measure the time from when I hit the solution on the Start Page to the point I could interact (mouse cursor active and able to hit the keyboard) with the code in that one file when it opens up again.

I did 4 tests that all gave me 20-25 sec load time.

Maybe Visual Studio does some caching of the solution? I’m not sure. But that is just part of it. So maybe it takes longer the very first time you load it.

But that’s just one time and (IMO) should not matter!

I really feel that 25 seconds is perfectly acceptable load time for a solution of this size.

Other loading performance tips and tricks

If you are still unsatisfied with the performance you can try looking at Visual Studio Performance Tips and Tricks and Performance considerations for large solutions that contain things like:

• Unload projects
  • You can manually unload rarely used individual projects from Solution Explorer using the right-click context menu. This is probably not an option for 400+ project.
• Disable Full Solution Analysis
  • Tools > Options > Text Editor > <Visual Basic or C#>. Then choose Advanced and deselect Enable full solution analysis
• Disabling CodeLens
  • Tools > Options > Text Editor > All Languages > CodeLens. Deselect Enable CodeLens
• Adjusting File Caching Threshold (step 3)
• Disabling Solution Crawler (step 4)
  • stop populating the task list with TODO comments etc.
• Optimize Visual Studio startup time and disable tools and extensions

Disable “Reopen Documents on solution load”

There is a feature comming in VS2017 Update 8 that can also help with loading time. Try it out in the preview version.

2. Build

There are quite few possible solutions to consider here.

Hardware solution?

First make sure there is a SSD drive in your computer.

Windows+s “defrag” + enter. Media type should say “Solid state drive”.

If it doesn’t get one now! This will make your build go much much faster.

Use a 64-bit OS

A 64-bit version, you expand the amount of virtual memory available to Visual Studio from 2 GB to 4 GB. This enables Visual Studio to handle significantly larger workloads even though it is 32-bit process.

Turn off Windows Defender for Visual studio

Go to Windows Defender -> Settings (the gear in the bottom left corner), then click “Virus & threat protection settings”, scroll down to “Add or remove exclusions” and click “Add an exclusion”

Now you need to add

• 1 folder (where your code lives. In my case c://dev)
• 2 process
  • devenv.exe
  • MSBuild.exe
  • java.exe
  • javac.exe
  • ServiceHub.Host.CLR.x86

Use Parallel Builds

For Intel i7 processor you can build 8 projects in parallel and that number is set default in my VS. But I have a Lenovo ThinkPad P50 with an XEON processor.

I’m not sure how many more (if any) VS can build in parallel with the XEON. Currently the solution doesn’t build so I can’t try it out.

But if you know, please let me know.

Set Build Verbosity to Minimal

If logging is set to detailed/diagnostic, it will halt your build to a crawl.

The build time went from 7 min down to 3.5 min when the verbosity was changed from detailed to minimum. That is 50% faster!

Shift + F6 to just build current project

If you are just working in one project you don’t need to rebuild the whole solution.

I wish there was a shortcut that would only build the projects that I have checked out/changed code. Please let me know if that exists.

Move to .NET Core 2.1 if possible

.net Core is getting faster and faster building projects. I have not seen a comparison between .net framework and .net Core on that but it seems that the major performance progress is made in .net Core.

Create custom build Configurations

You can create custom build configurations to add to your default debug,release ones and only include the projects you want/need to build.

The new build configurations get included into the .sln file so it would be best if you use only one and somebody organized can create the build definitions needed.

Refactor the solution and use nuget?

Here is a drastic one to think about!

How about braking the solution up into smaller solutions and create nuget packages from the projects? The main solution could then contain fewer projects with just nuget packages.

This way you are (I’m probably stretching the term here! :-)) adhering to the S in SOLID principle by making each solution do “one thing”.

Of course this is isn’t always possible (or easy) because of how the the application works. This is something that needs to be valuated on “solution by solution” bases.

Reduce the amount of projects

The fewer projects, the faster the compiler finishes building. Maybe you don’t need all these projects?

Incredibuild?

There is also the option of using 3rd party build agent IncrediBuild for Visual Studio. I have not tried it so I don’t know how it performance but since it is included as an option in components for Visual Studio install I wanted to mention it here.

Turn off unnecessary Services

Why have something running that you don’t really need? Go to this link and set all the services you like to manual.

And how fast was the build?

I’m still working on setting this all up and getting the build to run. But I got a college to run the build and with log verbosity on details it took him 7 minutes and with verbosity at minimum he was at 3.5.

I’m going to get him to try out every thing on this list so see if we can’t improve the build time even more.

Conclusion

I really hope you found all of this useful. There should be one or two things in there for you to try out.

If you have something to add please contact me at twitter.