Visual Studio 2015 – Don’t trust the package restore

I ran into a problem at work the other day, after a branch merge all icons disappeared in our webapp for me.

We recently introduced a new build step in SASS where we colorize our SVG-icons, so it wasn’t too hard to figure out what had changed. What caused it though was a whole other problem, as no other team member had the same problem as me.

After sprinkling some log prints in the SASS-function used to fix our icons, it was evident it wasn’t being run at all. Fun thing was, there were no errors reported during the build step either.

The automatic package restore

After some head scratching I decided to check versions of the npm packages in use. It turned out that this was ‘des pudels kern’.
The version of gulp-sass was specified as v2.1.1 in the package.json file, but on disk I had v1.3.3. I was naively thinking that the package versions would be correct since Visual Studio does a ‘Package Restore’ when loading a solution.

Loading a solution and running package restore is what happens when you swap branch, which I had done several times when I ran in to this issue.

Npm Install

Behind the scenes the Package Restore step is running ‘npm install’. So question is, was it a problem with the npm tooling or a Visual Studio issue?

Whatever the reason, the important thing is to know that Visual Studio’s ‘npm install’ isn’t to be trusted. Always check your npm packages after having version dependencies updated from a merge or pull.

Effects of Package Restore

Personally I think that this “Package Restore” behavior needs to be changed. When running larger solutions containing several Web Projects you’ll end up with a npm install running for all projects in the Solution when you open it or change branch.

At work we got a fairly large Solution with about 10 projects in it, and just swapping branch takes 15 minutes for the package restore, often more as my VS2015 crashes mid operation every other time. And then it takes 15 minutes more for the package restore that happens when I have to start up the studio again and load the solution.

My work machine is a three year old laptop, but it has got an i7 and 8GB of ram. Still it totally bogs down when the package restore is being run. And as web development should be accessible to all, it’s unfair to require a new stationary machine just to have a sane working development flow.

Improving Package Restore

First of all, the Package Restore functionality should be an option in the Visual Studio web tooling. I’ve seen rumors it’s possible to turn it off by disabling all External Web Tooling under Options, but this seems very clunky and quite the opposite of what we really want.

Even better would be if Visual Studio checked all installed packages and saw if they already matched what was specified in package.json. Vióla, no need for unnecessary restores!

Oh, and if any one on the VS Team get’s to read this, clicking the bower_components folder totally hangs my VS too!

In Closing

If you are having the same issues or just agree with the improvement suggestions, please help forward these concerns to the Visual Studio Web Tooling Team!

Happy Coding! 🙂

PS. Yes, I have used the feedback tool in Visual Studio. Many times. With no response. DS.