Docker containers are a lightweight alternative to full virtual machines that abstract the file system of the host operating system but are otherwise isolated. While popular for service deployments as a complete means of acquisition, containers are also useful for isolating build and test environments.
You can install Visual Studio 2017 and the Build Tools into a Docker container using the command line interactively or using a _Dockerfile_ such as the example below.
We are tracking and working to resolve some issues customers have reported and that we have also experienced. What follows is not comprehensive but some of the more common issues people are experiencing.
- Installing Visual Studio 2013, 2015, or 2017 on
microsoft/windowsservercore:10.0.14393.1593(which may be your locally cached:latestdepending on when you last pulled) fails. The bootstrapper fails to launch the installer. Please use either an older tagged build like:10.0.14393.1480or newer tagged build like:10.0.14393.1715– the current:latestwhen this post was first published. - When using PowerShell as your
SHELL, theStart-Processcmdlets may not set$LASTEXITCODEor$?. This is not a problem with the bootstrapper, but does require a workaround like:$p = start-process -wait -passthru -file c:vs_buildtools.exe -args '--installPath c:build'; if ($p.ExitCode) { throw ("Install failed: 0x{0:x}" -f $p.ExitCode) }
In the example above, any failures to install the selected workloads are captured in the container’s %TEMP%vslogs.zip so if you find the container ID in which the command was running (it will be printed right after the command that will run, like ” —> Running in 55e4baeceea1″), you can copy it out of a stopped container.
docker cp 55e4baeceea1:C:UsersContainerAdministratorAppDataLocalTempvslogs.zip "%TEMP%vslogs.zip"
The install logs like dd_setup_*_errors.log will have more details, and if there isn’t already an issue on https://developercommunity.visualstudio.com please open one with vslogs.zip attached.