No container image for Build Tools for Visual Studio 2017

After having written documentation about installing Build Tools for Visual Studio 2017 and working with partners to set up validation starting with Visual Studio 2017 Version 15.7, a common question from customers and partners alike is: are you going to publish a container image in a Docker registry? With DockerCon 2018 in full swing, there’s no better time to answer this question.

In short, we have no plans to publish such an image. A full Build Tools image is currently ~58GB and contains support for more workloads than probably any developer needs.

We are interested in common customer workload requirements and scenarios and are exploring options to simplify deployment of build environments. Perhaps someday we may publish one or more container images. This is why the documentation exists now: to aide our customers and partners to tailor a container image to fit their needs. In Visual Studio 2017 Version 15.7 we made significant improvements to the Build Tools SKU to increase the number of workloads it supports since running the Visual Studio IDE (or even just using its build toolchain) in a container is not supported. This also greatly increased the size for a full install from previous releases when installing into a container was not officially supported but mostly worked.

For example, to build the setup engine and installer shell, we would use a Dockerfile similar to the following:

# escape=`

# Copyright (C) Microsoft Corporation. All rights reserved.

# ARG FROM_IMAGE=microsoft/dotnet-framework:4.7.1-sdk-windowsservercore-1709
ARG FROM_IMAGE=microsoft/dotnet-framework:3.5-sdk-windowsservercore-1709
FROM ${FROM_IMAGE}

# Reset the shell.
SHELL ["cmd", "/S", "/C"]

# Set up environment to collect install errors.
COPY Install.cmd C:\TEMP\
ADD https://aka.ms/vscollect.exe C:\TEMP\collect.exe

# Install Node.js LTS
ADD https://nodejs.org/dist/v8.11.3/node-v8.11.3-x64.msi C:\TEMP\node-install.msi
RUN start /wait msiexec.exe /i C:\TEMP\node-install.msi /l*vx "%TEMP%\MSI-node-install.log" /qn ADDLOCAL=ALL

# Download channel for fixed installed.
ARG CHANNEL_URL=https://aka.ms/vs/15/release/channel
ADD ${CHANNEL_URL} C:\TEMP\VisualStudio.chman

# Download and install Build Tools for Visual Studio 2017.
ADD https://aka.ms/vs/15/release/vs_buildtools.exe C:\TEMP\vs_buildtools.exe
RUN C:\TEMP\Install.cmd C:\TEMP\vs_buildtools.exe –quiet –wait –norestart –nocache `
–channelUri C:\TEMP\VisualStudio.chman `
–installChannelUri C:\TEMP\VisualStudio.chman `
–add Microsoft.VisualStudio.Workload.ManagedDesktopBuildTools `
–add Microsoft.Net.Component.3.5.DeveloperTools `
–add Microsoft.Net.ComponentGroup.4.6.2.DeveloperTools `
–add Microsoft.Net.ComponentGroup.TargetingPacks.Common `
–add Microsoft.VisualStudio.Component.TestTools.BuildTools `
–add Microsoft.VisualStudio.Workload.VCTools `
–add Microsoft.VisualStudio.Component.VC.140 `
–add Microsoft.VisualStudio.Component.VC.ATL `
–add Microsoft.VisualStudio.Component.VC.CLI.Support `
–add Microsoft.VisualStudio.Component.Windows10SDK.16299.Desktop `
–add Microsoft.VisualStudio.ComponentGroup.NativeDesktop.WinXP `
–add Microsoft.VisualStudio.Workload.NodeBuildTools `
–add Microsoft.VisualStudio.Component.TypeScript.2.8 `
–installPath C:\BuildTools

# Use developer command prompt and start PowerShell if no other command specified.
ENTRYPOINT C:\BuildTools\Common7\Tools\VsDevCmd.bat &&
CMD ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]

This uses a slightly older Windows container image since the continuous integration agent runs Windows Server 2016.

Like with this example, you can construct a Dockerfile with whatever tools and libraries you need and either publish it to your own container registry or have developers build and maintain images from source. You could even simplify the process of building and running within the image using docker-compose. This Dockerfile only took ~10 minutes to build and is ~22.5GB (which includes the base image size of ~9GB) expanded. Depending on your network bandwidth building the image could be faster or at least less strain on network infrastructure.