Installieren von Build Tools in einem Container

Sie können Visual Studio Build Tools in einem Windows-Container installieren, um CI/CD-Workflows (Continuous Integration und Continuous Delivery) zu unterstützen. In diesem Artikel erfahren Sie, welche Docker-Konfigurationsänderungen erforderlich sind, sowie welche Workloads und Komponenten Sie in einem Container installieren können.

Container stellen eine hervorragende Möglichkeit dar, aus einem konsistenten Buildsystem ein Paket zu erstellen, welches Sie nicht nur in einer CI/CD-Serverumgebung, sondern auch in Entwicklungsumgebungen nutzen können. Sie können z.B. Ihren Quellcode in einen Container einbinden, der von einer benutzerdefinierten Umgebung erstellt werden soll, und parallel Visual Studio oder andere Tools verwenden, um Code zu schreiben. Wenn Ihr CI/CD-Workflow das gleiche Containerimage verwendet, können Sie sicher sein, dass Ihr Code konsistent erstellt wird. Sie können Container auch zum Erreichen von Runtime-Konsistenz verwenden, was bei Microservices üblich ist, die mithilfe eines Orchestrierungssystems mehrere Container nutzen. Dieser Aspekt wird in diesem Artikel jedoch nicht behandelt.

Wenn Sie Ihren Quellcode mithilfe von Visual Studio Build Tools nicht erstellen können, können Sie die gleichen Schritte auch auf andere Visual Studio-Produkte anwenden. Beachten Sie allerdings, dass Windows-Container keine interaktiven Benutzeroberflächen unterstützen und daher alle Befehle automatisiert werden müssen.

Voraussetzungen

Für dieses Thema wird davon ausgegangen, dass Sie zu einem gewissen Grad mit Docker vertraut sind. Wenn Sie noch nicht mit der Ausführung von Docker unter Windows vertraut sind, informieren Sie sich über das Installieren und Konfigurieren der Docker-Engine unter Windows.

Das folgende Basisimage ist ein Beispiel und funktioniert für Ihr System möglicherweise nicht. Lesen Sie den Artikel Kompatibilität von Windows-Containerversionen, um zu ermitteln, welches Basisimage Sie für Ihre Umgebung verwenden sollten.

Erstellen und Kompilieren der Dockerfile-Datei

Speichern Sie die folgende Dockerfile-Beispieldatei in einer neuen Datei auf Ihrem Datenträger. Wenn Sie die Datei einfach „Dockerfile“ nennen, wird sie standardmäßig erkannt.

1. Öffnen Sie eine Eingabeaufforderung.

2. Erstellen Sie ein neues Verzeichnis (empfohlen):

   mkdir C:\BuildTools
   

3. Ändern Sie die Verzeichnisse auf dieses neue Verzeichnis:

   cd C:\BuildTools
   

4. Speichern Sie den folgenden Inhalt unter C:\BuildTools\Dockerfile.

   # escape=`
   
   # Use the latest Windows Server Core 2019 image.
   FROM mcr.microsoft.com/windows/servercore:ltsc2019
   
   # Restore the default Windows shell for correct batch processing.
   SHELL ["cmd", "/S", "/C"]
   
   RUN `
       # Download the Build Tools bootstrapper.
       curl -SL --output vs_buildtools.exe https://aka.ms/vs/16/release/vs_buildtools.exe `
       `
       # Install Build Tools with the Microsoft.VisualStudio.Workload.AzureBuildTools workload, excluding workloads and components with known issues.
       && (start /w vs_buildtools.exe --quiet --wait --norestart --nocache `
           --installPath "%ProgramFiles(x86)%\Microsoft Visual Studio\2019\BuildTools" `
           --add Microsoft.VisualStudio.Workload.AzureBuildTools `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.10240 `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.10586 `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.14393 `
           --remove Microsoft.VisualStudio.Component.Windows81SDK `
           || IF "%ERRORLEVEL%"=="3010" EXIT 0) `
       `
       # Cleanup
       && del /q vs_buildtools.exe
   
   # Define the entry point for the docker container.
   # This entry point starts the developer command prompt and launches the PowerShell shell.
   ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]
   

   Tipp

   Um die 64-Bit-Version als Ziel festzulegen, geben Sie die -arch=amd64-Option im ENTRYPOINT-Befehl an, um die Entwickler-Eingabeaufforderung für Visual Studio (VSDevCmd.bat) zu starten.

   Beispiel: ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "-arch=amd64", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]

   Warnung

   Wenn Sie Ihr Image direkt auf der Grundlage von microsoft/windowsservercore erstellen, wird .NET Framework möglicherweise nicht ordnungsgemäß installiert, ohne dass ein Installationsfehler ausgegeben wird. Es kann sein, dass verwalteter Code nach Abschluss der Installation nicht ausgeführt wird. Erstellen Sie Ihr Image stattdessen auf der Grundlage von microsoft/dotnet-framework:4.8] oder höher. Beachten Sie außerdem, dass Images der Version 4.8 oder höher möglicherweise PowerShell als Standard-SHELL verwenden, wodurch die Anweisungen RUN und ENTRYPOINT nicht ausgeführt werden können.

   Informationen dazu, welche Containerbetriebssystemversionen auf welchen Hostbetriebssystemversionen unterstützt werden, finden Sie unter Kompatibilität der Windows-Containerversionen. Informationen zu bekannten Problemen finden Sie unter Bekannte Probleme bei Containern.

   # escape=`
   
   # Use the latest Windows Server Core 2022 image.
   FROM mcr.microsoft.com/windows/servercore:ltsc2022
   
   # Restore the default Windows shell for correct batch processing.
   SHELL ["cmd", "/S", "/C"]
   
   RUN `
       # Download the Build Tools bootstrapper.
       curl -SL --output vs_buildtools.exe https://aka.ms/vs/17/release/vs_buildtools.exe `
       `
       # Install Build Tools with the Microsoft.VisualStudio.Workload.AzureBuildTools workload, excluding workloads and components with known issues.
       && (start /w vs_buildtools.exe --quiet --wait --norestart --nocache `
           --installPath "%ProgramFiles(x86)%\Microsoft Visual Studio\2022\BuildTools" `
           --add Microsoft.VisualStudio.Workload.AzureBuildTools `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.10240 `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.10586 `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.14393 `
           --remove Microsoft.VisualStudio.Component.Windows81SDK `
           || IF "%ERRORLEVEL%"=="3010" EXIT 0) `
       `
       # Cleanup
       && del /q vs_buildtools.exe
   
   # Define the entry point for the docker container.
   # This entry point starts the developer command prompt and launches the PowerShell shell.
   ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]
   

   Tipp

   Um die 64-Bit-Version als Ziel festzulegen, geben Sie die -arch=amd64-Option im ENTRYPOINT-Befehl an, um die Entwickler-Eingabeaufforderung für Visual Studio (VSDevCmd.bat) zu starten.

   Beispiel: ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "-arch=amd64", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]

   Warnung

   Wenn Sie Ihr Image direkt auf der Grundlage von microsoft/windowsservercore erstellen, wird .NET Framework möglicherweise nicht ordnungsgemäß installiert, ohne dass ein Installationsfehler ausgegeben wird. Es kann sein, dass verwalteter Code nach Abschluss der Installation nicht ausgeführt wird. Erstellen Sie Ihr Image stattdessen auf der Grundlage von microsoft/dotnet-framework:4.8 oder höher. Beachten Sie außerdem, dass Images der Version 4.8 oder höher möglicherweise PowerShell als Standard-SHELL verwenden, wodurch die Anweisungen RUN und ENTRYPOINT nicht ausgeführt werden können.

   Informationen dazu, welche Containerbetriebssystemversionen auf welchen Hostbetriebssystemversionen unterstützt werden, finden Sie unter Kompatibilität der Windows-Containerversionen. Informationen zu bekannten Problemen finden Sie unter Bekannte Probleme bei Containern.

   Hinweis

   Der Fehlercode 3010 wird verwendet, um den Erfolg eines erforderlichen Neustarts anzuzeigen. Weitere Informationen finden Sie unter MsiExec.exe-Fehlermeldungen.

5. Führen Sie den folgenden Befehl innerhalb jenes Verzeichnisses aus.

   docker build -t buildtools2019:latest -m 2GB .
   

   Dieser Befehl erstellt die Dockerfile-Datei im aktuellen Verzeichnis. Dies erfordert 2 GB an Arbeitsspeicher. Standardmäßig steht dafür 1 GB zur Verfügung. Dies ist jedoch zum Installieren einiger Workloads nicht ausreichend. Abhängig von Ihren Buildanforderungen reicht dies möglicherweise dennoch aus.

   Das endgültige Image trägt die Markierung buildtools2019:latest, sodass Sie es problemlos als buildtools2019 in einem Container ausführen können, da das Tag „latest“ standardmäßig verwendet wird, wenn kein Tag angegeben wurde. Wenn Sie eine bestimmte Version von Visual Studio Build Tools 2019 in einem komplexeren Szenario verwenden möchten, können Sie den Container stattdessen mit einer bestimmten Visual Studio-Buildnummer sowie dem Tag „latest“ markieren, damit die Container eine bestimmte Version konsistent verwenden.

   docker build -t buildtools:latest -m 2GB .
   

   Dieser Befehl erstellt die Dockerfile-Datei im aktuellen Verzeichnis. Dies erfordert 2 GB an Arbeitsspeicher. Standardmäßig steht dafür 1 GB zur Verfügung. Dies ist jedoch zum Installieren einiger Workloads nicht ausreichend. Abhängig von Ihren Buildanforderungen reicht dies möglicherweise dennoch aus.

   Das endgültige Image trägt die Markierung „buildtools:latest“, sodass Sie es problemlos als „buildtools“ in einem Container ausführen können, da das Tag „latest“ standardmäßig verwendet wird, wenn kein Tag angegeben wurde. Wenn Sie eine bestimmte Version von Visual Studio Build Tools in einem komplexeren Szenario verwenden möchten, können Sie den Container stattdessen mit einer bestimmten Visual Studio-Buildnummer sowie dem Tag „latest“ markieren, damit die Container eine bestimmte Version konsistent verwenden.

Verwenden des erstellten Images

Da Sie bereits ein Image erstellt haben, können Sie dieses nun in einem Container ausführen, um sowohl interaktive, als auch automatisierte Builds abzudecken. Im Beispiel wird die Developer-Eingabeaufforderung verwendet, damit Ihre PATH-Variable und andere Umgebungsvariablen bereits konfiguriert sind.

1. Öffnen Sie eine Eingabeaufforderung.

2. Führen Sie den Container aus, um eine PowerShell-Umgebung zu starten, in der alle Entwicklerumgebungsvariablen festgelegt sind:

   docker run -it buildtools2019
   

   docker run -it buildtools
   

Wenn Sie dieses Image für Ihren CI/CD-Workflow verwenden möchten, können Sie es in Ihrer eigenen Azure Container Registry oder in einer anderen internen Docker-Registrierung veröffentlichen, damit die Server es nur abrufen müssen.

Problembehandlung bei Windows- und Build Tools-Containern

Es gibt einige Probleme bei der Installation von Visual Studio in einem Docker-Container.

Problembehandlung bei Windows-Containern

Die folgenden bekannten Probleme treten auf, wenn Sie Visual Studio Build Tools in einem Windows-Container installieren.

• Übergeben Sie -m 2GB (oder mehr), wenn Sie das Image erstellen. Einige Workloads erfordern bei der Installation mehr Arbeitsspeicher als die standardmäßigen 1 GB.

• Sie müssen Docker konfigurieren, damit Sie Datenträger verwenden können, die größer als die standardmäßig festgelegten 20 GB sind.

• Übergeben Sie --norestart auf der Befehlszeile. Beim Versuch, einen Windows-Container von innerhalb des Container neu zu starten, wird ERROR_TOO_MANY_OPEN_FILES an den Host zurückgegeben (Stand: Veröffentlichung dieses Artikels).

• Wenn Sie Ihr Image direkt auf der Grundlage von mcr.microsoft.com/windows/servercore erstellen, wird .NET Framework möglicherweise nicht ordnungsgemäß installiert, ohne dass ein Installationsfehler ausgegeben wird. Es kann sein, dass verwalteter Code nach Abschluss der Installation nicht ausgeführt wird. Erstellen Sie Ihr Image stattdessen auf der Grundlage von microsoft/dotnet-framework:4.7.1 oder höher. Beispielsweise kann beim Erstellen mit MSBuild ein Fehler angezeigt werden, der dem folgenden ähnelt:

  C:\BuildTools\MSBuild\15.0\bin\Roslyn\Microsoft.CSharp.Core.targets(84,5): error MSB6003: The specified task executable "csc.exe" could not be run. Could not load file or assembly 'System.IO.FileSystem, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. (Fehler MSB6003: Die angegebene ausführbare Datei des Tasks (csc.exe) konnte nicht ausgeführt werden. Die Datei oder Assembly 'System.IO.FileSystem, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a', oder eine Abhängigkeit davon, wurde nicht gefunden.) Die angegebene Datei wurde nicht gefunden.“

Problembehandlung bei Build Tools-Containern

Die folgenden bekannten Probleme treten möglicherweise auf, wenn Sie einen Build Tools-Container verwenden. Um festzustellen, ob Probleme behoben wurden oder ob es andere bekannte Probleme gibt, besuchen Sie die Entwicklercommunity.

• IntelliTrace funktioniert in einigen Szenarios innerhalb eines Containers möglicherweise nicht.
• In älteren Versionen von Docker für Windows beträgt die Standardgröße für Containerimages nur 20 GB und bietet nicht genügend Platz für Build Tools. Hier finden Sie Anweisungen zum Ändern der Imagegröße auf 127 GB oder mehr. Sehen Sie sich die Protokolldateien an, um bestätigen zu können, ob ein Speicherplatzproblem vorliegt. Wenn der Speicherplatz ausgeht, enthält Ihre vslogs\dd_setup_<timestamp>_errors.log-Datei Folgendes:

Pre-check verification: Visual Studio needs at least 91.99 GB of disk space. Try to free up space on C:\ or change your target drive.
Pre-check verification failed with error(s) :  SizePreCheckEvaluator.

Zugehöriger Inhalt

• Erweitertes Beispiel für Container
• Workload- und Komponenten-IDs in Visual Studio Build Tools