We have a few legacy boat anchors. All of our customers are on Windows so our nodejs C++ addons have to be built for Windows. We have a C++ project stuck in vs2013. We have an integration/functional testing framework written in C#.
Nodejs was the first headache. And the windows-build-tools npm is the least bad option to end that headache. Installs python. Installs enough of visual studio 2015/2017’s build tools. Spews piles of repeated output. It runs both installs at the same time. And tries to keep the output readable from both at the same time.
Under the excuse “We’ll change nodejs more often than Visual Studio” I went the chocolatey route. Python plays nice with windows-build-tools. Visual Studio… not so much. Further digging I thought “Well, le’s run vs_BuiltTools.exe with the right parameters and wait on that.” No joy. It does the windows equivalent of a double fork that then creates a race condition while windows-build-tools installs. The final kludge.
$returnCode = Start-Process -FilePath vs_BuildTools.exe -ArgumentList "--wait", "--norestart", "--quiet", "--includeRecommended", "--add Microsoft.VisualStudio.Workload.VCTools" -Wait -PassThru
That let the install play nice in a Docker Containers for Windows Dockerfile. Not communicating on nodejs changes broke the concept.
C# was the next headache. Chocolatey’s visualstudio2017community and visualstudio2017-workload-netcoretools and netfx-4.6.2-devpack to the rescue.
VS2013 was only a mild headache. The chocolatey ‘visualstudio2013community’ package does not work inside docker.