Installer Build Tools dans un conteneur

S’applique à :ouiVisual Studio nonVisual Studio pour Mac nonVisual Studio Code

Vous pouvez installer Visual Studio Build Tools dans un conteneur Windows pour prendre en charge les flux de travail d’intégration continue (CI) et de livraison continue(CD). Cet article vous explique comment procéder aux modifications nécessaires de la configuration Docker, et vous donne les charges de travail et composants que vous pouvez installer dans un conteneur.

Les conteneurs sont un excellent moyen d’empaqueter un système de génération cohérent, que vous pouvez utiliser non seulement dans un environnement serveur CI/CD, mais également dans un environnement de développement. Par exemple, vous pouvez monter du code source dans un conteneur pour qu’il soit généré par un environnement personnalisé, tout en continuant à utiliser Visual Studio ou d’autres outils pour écrire votre code. Si votre flux de travail CI/CD utilise la même image de conteneur, vous avez la garantie que votre code est généré de manière cohérente. Vous pouvez également utiliser des conteneurs à des fins de cohérence d’exécution, ce qui est courant pour les microservices qui utilisent plusieurs conteneurs avec un système d’orchestration. Toutefois, cela dépasse le cadre de cet article.

Si Visual Studio Build Tools n’a pas ce dont vous avez besoin pour générer votre code source, vous pouvez utiliser ces étapes pour d’autres produits Visual Studio. Notez, toutefois, que les conteneurs Windows ne prennent pas en charge les interfaces utilisateur interactives, et que toutes les commandes doivent être automatisées.

Avant de commencer

Il est utile d’acquérir des connaissances sur Docker pour ce qui suit. Si vous n’êtes pas déjà familiarisé avec l’exécution de Docker sur Windows, découvrez comment installer et configurer le moteur Docker sur Windows.

L’image de base ci-dessous est un exemple et peut ne pas fonctionner pour votre système. Lisez compatibilité des versions du conteneur Windows pour déterminer quelle image de base utiliser pour votre environnement.

Créer et générer le fichier Dockerfile

Enregistrez l’exemple Dockerfile suivant dans un nouveau fichier sur votre disque. Si le fichier se nomme simplement « Dockerfile », il est reconnu par défaut.

Avertissement

Cet exemple de fichier Dockerfile exclut seulement les anciens SDK Windows qui ne peuvent pas être installés dans des conteneurs. Les versions précédentes font échouer la commande de build.

  1. Ouvrez une invite de commandes.

  2. Créez un répertoire (recommandé) :

    mkdir C:\BuildTools
    
  3. Remplacez les répertoires par ce nouveau répertoire :

    cd C:\BuildTools
    
  4. Enregistrez le contenu suivant dans 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"]
    

    Conseil

    Pour obtenir la liste des charges de travail et des composants, consultez le répertoire des composants Visual Studio Build Tools.

    Avertissement

    Si vous basez votre image directement sur microsoft/windowsservercore, l’installation du .NET Framework risque de ne pas s’effectuer correctement et aucune erreur d’installation ne sera signalée. Le code managé risque de ne pas s’exécuter une fois l’installation terminée. Basez plutôt votre image sur microsoft/dotnet-framework:4.8 ou une version ultérieure. Notez également que les images marquées avec la version 4.8 ou ultérieure sont susceptibles d’utiliser PowerShell comme SHELL par défaut, ce qui provoque l’échec des instructions RUN et ENTRYPOINT.

    Consultez la page Compatibilité des versions de conteneur Windows pour voir quelles versions de conteneur du système d’exploitation sont prises en charge sur les versions de système d’exploitation hôte, et la page Problèmes connus liés aux conteneurs pour les problèmes connus.

    # 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"]
    

    Conseil

    Pour obtenir la liste des charges de travail et des composants, consultez le répertoire des composants Visual Studio Build Tools.

    Avertissement

    Si vous basez votre image directement sur microsoft/windowsservercore, l’installation du .NET Framework risque de ne pas s’effectuer correctement et aucune erreur d’installation ne sera signalée. Le code managé risque de ne pas s’exécuter une fois l’installation terminée. Basez plutôt votre image sur microsoft/dotnet-framework:4.8 ou une version ultérieure. Notez également que les images marquées avec la version 4.8 ou ultérieure sont susceptibles d’utiliser PowerShell comme SHELL par défaut, ce qui provoque l’échec des instructions RUN et ENTRYPOINT.

    Consultez la page Compatibilité des versions de conteneur Windows pour voir quelles versions de conteneur du système d’exploitation sont prises en charge sur les versions de système d’exploitation hôte, et la page Problèmes connus liés aux conteneurs pour les problèmes connus.

    Notes

    Le code 3010 d’erreur est utilisé pour indiquer la réussite d’un redémarrage requis. Pour plus d’informations, consultez MsiExec.exe messages d’erreur .

  5. Exécutez la commande suivante dans ce répertoire.

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

    Cette commande permet de générer le fichier Dockerfile dans le répertoire actif, en utilisant 2 Go de mémoire. La valeur par défaut de 1 Go n’est pas suffisante quand certaines charges de travail sont installées ; la possibilité de générer avec seulement 1 Go de mémoire dépend cependant des exigences de votre build.

    L’image finale est étiquetée « buildtools2019:latest » : vous pouvez donc l’exécuter facilement dans un conteneur en tant que « buildtools2019 », car l’étiquette « latest » est la valeur par défaut si aucune étiquette n’est spécifiée. Si vous voulez utiliser une version spécifique de Visual Studio Build Tools 2019 dans un scénario avancé, étiquetez le conteneur avec un numéro de build Visual Studio spécifique et avec « latest », pour que les conteneurs puissent utiliser la même version.

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

    Cette commande permet de générer le fichier Dockerfile dans le répertoire actif, en utilisant 2 Go de mémoire. La valeur par défaut de 1 Go n’est pas suffisante quand certaines charges de travail sont installées ; la possibilité de générer avec seulement 1 Go de mémoire dépend cependant des exigences de votre build.

    L’image finale est marquée « buildtools:latest » pour vous permettre de l’exécuter facilement dans un conteneur en tant que « buildtools », car la balise « latest » est la balise par défaut si aucune balise n’est spécifiée. Si vous souhaitez utiliser une version spécifique de Visual Studio Build Tools dans un scénario plus avancé, vous pouvez plutôt baliser le conteneur avec un numéro de build Visual Studio spécifique ainsi que « dernière » afin que les conteneurs puissent utiliser une version spécifique de manière cohérente.

Utilisation de l’image générée

Maintenant que vous avez créé une image, vous pouvez l’exécuter dans un conteneur pour effectuer des générations automatisées et interactives. L’exemple utilise l’invite de commandes développeur. Votre chemin (PATH) et autres variables d’environnement sont donc déjà configurés.

  1. Ouvrez une invite de commandes.

  2. Exécutez le conteneur pour démarrer un environnement PowerShell avec toutes les variables d’environnement développeur définies :

    docker run -it buildtools2019
    
    docker run -it buildtools
    

Pour utiliser cette image pour votre workflow CI/CD, vous pouvez la publier dans votre propre instance Azure Container Registry ou dans un autre registre Docker interne, pour que les serveurs doivent seulement l’extraire.

Notes

Si le conteneur Docker ne parvient pas à démarrer, il y a probablement un problème d’installation de Visual Studio. Vous pouvez mettre à jour le fichier Dockerfile pour supprimer l’étape qui appelle la commande de lot Visual Studio. Cela vous permet de démarrer le conteneur Docker et de lire les journaux des erreurs d’installation.

Dans votre fichier Dockerfile, supprimez les C:\\BuildTools\\Common7\\Tools\\VsDevCmd.bat paramètres et && de la ENTRYPOINT commande . La commande doit maintenant être ENTRYPOINT ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]. Ensuite, régénérez le fichier Dockerfile et exécutez la run commande pour accéder aux fichiers conteneur. Pour localiser les journaux des erreurs d’installation, accédez au $env:TEMP répertoire et recherchez le dd_setup_<timestamp>_errors.log fichier.

Après avoir identifié et résolu le problème d’installation, vous pouvez rajouter les C:\\BuildTools\\Common7\\Tools\\VsDevCmd.bat paramètres et && à la ENTRYPOINT commande et reconstruire votre fichier Dockerfile.

Pour plus d’informations, consultez Problèmes connus liés aux conteneurs.

Support ou résolution des problèmes

Parfois, des problèmes peuvent se produire. Si votre installation de Visual Studio échoue, consultez Résolution des problèmes d’installation et de mise à niveau de Visual Studio pour obtenir une aide pas à pas.

Voici d’autres options de support :

Voir aussi