/* MINDFIRE BLOG */

On installation, Visual Studio gives developers the choice to install Node.js tools for working with the framework, and for integrating JavaScript build tools with Visual Studio’s own build process. This allows developers to use any tools they deem necessary – such as Webpack, Grunt, Gulp, etc. – and use them without having to leave the IDE to make them work. It is a nice time saving feature that can really help speed up development time, and bring developers with expertise in platforms other than Microsoft’s own C# into the Microsoft developer world.

JavaScript and Node are both progressing at a very quick pace; with new features being added into the ECMAScript standard every year, and a new version of Node at about the same frequency. This is good for developers using those technologies, as these new features usually introduce time saving features and new abilities that can make development in JavaScript easier. These features include things like the const keyword, along with lambda expressions and a new class syntax. To use these new features, a developer would obviously need to upgrade the instance of Node.js installed to a version that supports the newer features.

Herein lies the problem, however. Visual Studio does not perform a traditional install of Node.js into the Program Files folder as the Node MSI would. Instead, Visual Studio opts to install the instance into its own location and use it there. The reasons for this seem to be so that Visual Studio can own its copy of Node and control how it is supposed to operate – including automatically installing a few global packages and keeping to the version it expects. If Node is installed later by the developer, it will be installed into the Program Files folder as expected, and these two instances will live in parallel to each other.

All of this is fine, expect when a developer is expecting to have certain features enabled (because he or she installed a version of Node that supports those features), and Visual Studio’s build process fails to recognize the newer syntax. The method typically used to get around this is to just rebuild the code from a console window which will use the correct version of Node. This makes it pointless to use the Node integration with Visual Studio, and so the developer loses time by working around the problem.

To force Visual Studio to use the version of Node the developer has installed, you can replace the files Visual Studio installed with symbolic links that will point to the versions in Program Files. Visual Studio keeps its copy of Node in the path C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Web\External. In this folder, there are two pieces that will need to be changed. First, the node_modules folder will need to be exchanged, and second, the Node executable will need to be exchanged.

To replace the two items, first make backup copies of each. For example, the Node executable can be renamed to Node.exe_bak, and the node_modules folder to node_modules_bak. Once a backup copy of these has been made, open up a command prompt window in Administrator mode. This can be done by searching for cmd in the Start menu, and then right-clicking and selecting “Run as Administrator”.

Once the cmd window has opened, change to the Visual Studio directory where Node is installed. Into the cmd window, type cd “C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Web\External” and press enter. You’ll then need to create a symbolic link for both the Node executable and the node_modules folder. To create the link for the node_modules folder, type in the following to the cmd window: mklink node_modules “C:\Program Files\nodejs\node_modules”. If you have installed the x86 version onto an x64 machine, make sure you add the (x86) part of the Program Files path. To create the link for the executable, type in the following: mklink Node.exe “C:\Program Files\nodejs\node.exe”. Again, if you are using the x86 version, make sure to use the correct path.

After running these commands, the Visual Studio versions of Node will be pointing at whichever version is currently installed through the MSI. If you are using a helper tool like NVM to manage your Node installations, this is even more useful because it’s a simple command to switch node versions for Visual Studio. The result is that you can now use whatever version of Node is required for the particular project on which you happen to be working.