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.

Vorbereitungen

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.

Warnung

Diese Dockerfile-Beispieldatei kann lediglich bei älteren Windows SDKs nicht verwendet werden, die nicht in Containern installiert werden können. Bei älteren Releases schlägt der Buildbefehl fehl.

  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 image with .NET Framework 4.7.2.
    FROM mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-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/15/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 C:\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:\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]
    

    Tipp

    Eine Liste der Workloads und Komponenten finden Sie unter Visual Studio Build Tools: Komponentenverzeichnis.

    Warnung

    Wenn Sie Ihr Image direkt auf der Grundlage von microsoft/windowsservercore oder mcr.microsoft.com/windows/servercore – siehe Microsoft syndicates container catalog (Microsoft veröffentlicht Containerkatalog) – 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.2 oder höher. Beachten Sie außerdem, dass Images der Version 4.7.2 oder höher möglicherweise PowerShell als Standard-SHELL verwenden, wodurch die Anweisungen RUN und ENTRYPOINT nicht ausgeführt werden können.

    Visual Studio 2017 Version 15.8 und früher (alle Produkte) werden unter „mcr.microsoft.com/windows/servercore:1809“ oder höher nicht ordnungsgemäß installiert. Es wird keine Fehlermeldung angezeigt.

    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 image with .NET Framework 4.8.
    FROM mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-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 modify `
            --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

    Eine Liste der Workloads und Komponenten finden Sie unter Visual Studio Build Tools: Komponentenverzeichnis.

    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 image with .NET Framework 4.8.
    FROM mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-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/17/pre/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 modify `
            --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

    Eine Liste der Workloads und Komponenten finden Sie unter Visual Studio Build Tools: Komponentenverzeichnis.

    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 buildtools2017: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 „buildtools2017:latest“, sodass Sie es problemlos als „buildtools2017“ 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 2017 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 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 buildtools2017
    
    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.

Hinweis

Wenn der Docker-Container nicht gestartet werden kann, liegt vermutlich ein Visual Studio-Installationsproblem vor. Sie können das Dockerfile aktualisieren, um den Schritt zu entfernen, der den Visual Studio-Batchbefehl aufruft. Dadurch können Sie den Docker-Container starten und die Installationsfehlerprotokolle lesen.

Entfernen Sie die Parameter C:\\BuildTools\\Common7\\Tools\\VsDevCmd.bat und && aus dem Befehl ENTRYPOINT in Ihrer Dockerfile-Datei. Der Befehl sollte nun wie folgt lauten: ENTRYPOINT ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]. Erstellen Sie das Dockerfile dann neu, und führen Sie den Befehl run aus, um auf die Containerdateien zuzugreifen. Navigieren Sie zum Verzeichnis $env:TEMP, und suchen Sie die Datei dd_setup_<timestamp>_errors.log, um die Installationsfehlerprotokolle zu finden.

Nachdem Sie das Installationsproblem identifiziert und behoben haben, können Sie die Parameter C:\\BuildTools\\Common7\\Tools\\VsDevCmd.bat und && wieder zum Befehl ENTRYPOINT hinzufügen und Ihr Dockerfile neu erstellen.

Weitere Informationen finden Sie unter Bekannte Probleme bei Containern.

Support aufrufen

Manchmal kann etwas schiefgehen. Wenn es bei der Installation von Visual Studio zu einem Fehler kommt, finden Sie ausführliche Informationen im Artikel Problembehandlung bei der Visual Studio-Installation und bei Upgradefehlern.

Für installationsbezogene Probleme wird außerdem eine Livechat-Supportoption angeboten (nur auf Englisch).

Hier sind einige weitere Supportoptionen:

Siehe auch