This will be a very negative post so I want to start off with saying that I love Visual Studio, it’s my favorite IDE for C++ and C# development. With that said the upgrade to VS2017 has been less than smooth.
I agree that Visual Studio has outgrown the old environment variable approach, however the implementation is lacking.
Not shipping the tooling in the box makes migrations a lot more painful than they should be. The user now has to download the tool in the buildsystem, likely hosting a copy somewhere to avoid Github issues causing builds to fail. This in turn means the user has to keep their local copy updated with new releases of the tool which doesn’t track the Visual Studio release schedule.
Alternatively the user can build the tool locally but then the issue instead becomes integrating that build into the system and keeping a local fork of the git repository.
Now you might say, use the Powershell module! That has all of the same drawbacks mentioned above.
Ship vswhere and the Powershell module in the box, update it through Visual Studio or keep it in sync with the larger update releases. Put it in the PATH or let me find it using an environment variable.
This was a good idea, I can keep back compat without having a full VS2015 install taking up disk space.
This doesn’t actually include the tools needed to actually use it. Trying to call vcvarsall.bat
it spits out the help usage message. The script actually tries to find the Microsoft C++ Build Tools 2015
which aren’t included in the install. Until these are installed vcvarsall.bat fails and does nothing.
If I select to install this component it should actually work and not require a separate download.
This is just two of the issues I’ve come across so far. There’s plenty more but it requires some more verification to make sure it’s not just me doing stupid things.