Installare Build Tools in un contenitore
È possibile installare Visual Studio Build Tools in un contenitore di Windows per supportare flussi di lavoro di integrazione continua e recapito continuo (CI/CD). Questo articolo illustra le modifiche di configurazione di Docker necessarie, nonché i carichi di lavoro e i componenti che è possibile installare in un contenitore.
I contenitori sono un ottimo modo per inserire un sistema di compilazione coerente in un pacchetto utilizzabile non solo in un ambiente server CI/CD, ma anche per gli ambienti di sviluppo. Ad esempio, è possibile montare il codice sorgente in un contenitore per la compilazione in un ambiente personalizzato, pur continuando a usare Visual Studio o altri strumenti per scrivere il codice. Se il flusso di lavoro CI/CD usa la stessa immagine del contenitore, è possibile essere certi che la compilazione del codice avvenga in modo coerente. È possibile usare i contenitori anche per la coerenza del runtime, un'esigenza comune per i microservizi che usano più contenitori con un sistema di orchestrazione, ma ciò esula dagli scopi di questo articolo.
Se Visual Studio Build Tools non include ciò che serve per la compilazione del codice sorgente, le stesse procedure sono valide anche per altri prodotti Visual Studio. Si noti, tuttavia, che i contenitori di Windows non supportano un'interfaccia utente interattiva, quindi tutti i comandi devono essere automatizzati.
Operazioni preliminari
Di seguito si presuppone una certa conoscenza di Docker. Se non si ha già familiarità con l'esecuzione di Docker in Windows, vedere le informazioni su come installare e configurare il motore Docker in Windows.
L'immagine di base riportata di seguito è un esempio e potrebbe non funzionare nel sistema specifico. Vedere Compatibilità delle versioni del contenitore Windows per determinare quale immagine di base è consigliabile usare per l'ambiente specifico.
Creare e compilare il Dockerfile
Salvare il Dockerfile di esempio seguente in un nuovo file su disco. Se il file è denominato semplicemente "Dockerfile", viene riconosciuto per impostazione predefinita.
Avviso
Questo Dockerfile di esempio esclude solo le versioni precedenti di Windows SDK che non possono essere installate in contenitori. Con le versioni precedenti il comando di compilazione ha esito negativo.
Apri un prompt dei comandi.
Creare una nuova directory (operazione consigliata):
mkdir C:\BuildTools
Passare alla nuova directory:
cd C:\BuildTools
Salvare il contenuto seguente in 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"]
Suggerimento
Per specificare come destinazione 64 bit, specificare l'opzione
-arch=amd64
nelENTRYPOINT
comando per avviare il prompt dei comandi per gli sviluppatori per Visual Studio (VSDevCmd.bat
).Ad esempio:
ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "-arch=amd64", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]
Avviso
Se si basa l'immagine direttamente su microsoft/windowsservercore, .NET Framework potrebbe non essere installato correttamente e non viene segnalato nessun errore di installazione. Il codice gestito potrebbe non essere eseguito dopo il completamento dell'installazione. Basare invece l'immagine su microsoft/dotnet-framework:4.8] o versione successiva. Si noti anche che le immagini contrassegnate con la versione 4.8 o versioni successive potrebbero usare PowerShell come
SHELL
predefinita, impedendo l'esecuzione delle istruzioniRUN
eENTRYPOINT
.Vedere Compatibilità delle versioni dei contenitori di Windows per verificare quali versioni del sistema operativo del contenitore sono supportate in quali versioni del sistema operativo host e Risoluzione dei problemi relativi ai contenitori di Windows e Build Tools per i problemi noti.
# 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"]
Suggerimento
Per specificare come destinazione 64 bit, specificare l'opzione
-arch=amd64
nelENTRYPOINT
comando per avviare il prompt dei comandi per gli sviluppatori per Visual Studio (VSDevCmd.bat
).Ad esempio:
ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "-arch=amd64", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]
Avviso
Se si basa l'immagine direttamente su microsoft/windowsservercore, .NET Framework potrebbe non essere installato correttamente e non viene segnalato nessun errore di installazione. Il codice gestito potrebbe non essere eseguito dopo il completamento dell'installazione. Basare invece l'immagine su microsoft/dotnet-framework:4.8 o versioni successive. Si noti anche che le immagini contrassegnate con la versione 4.8 o versioni successive potrebbero usare PowerShell come
SHELL
predefinita, impedendo l'esecuzione delle istruzioniRUN
eENTRYPOINT
.Vedere Compatibilità delle versioni dei contenitori di Windows per verificare quali versioni del sistema operativo del contenitore sono supportate in quali versioni del sistema operativo host e Risoluzione dei problemi relativi ai contenitori di Windows e Build Tools per i problemi noti.
Nota
Il codice
3010
di errore viene usato per indicare l'esito positivo di un riavvio necessario. Per altre informazioni, vedere MsiExec.exe messaggi di errore.Eseguire il comando seguente in tale directory.
docker build -t buildtools2019:latest -m 2GB .
Questo comando compila il Dockerfile nella directory corrente con 2 GB di memoria. Il valore predefinito 1 GB non è sufficiente quando vengono installati alcuni carichi di lavoro; Tuttavia, potrebbe essere possibile compilare con solo 1 GB di memoria a seconda dei requisiti di compilazione.
L'immagine finale è contrassegnata
buildtools2019:latest
in modo da poterla eseguire facilmente in un contenitore, perchébuildtools2019
il tag "latest" è l'impostazione predefinita se non viene specificato alcun tag. Se si vuole usare una versione specifica di Visual Studio Build Tools 2019 in uno scenario più avanzato, è possibile contrassegnare il contenitore con un numero di build di Visual Studio specifico e usare il tag "latest", in modo che i contenitori possano usare una versione specifica in modo coerente.docker build -t buildtools:latest -m 2GB .
Questo comando compila il Dockerfile nella directory corrente con 2 GB di memoria. L'impostazione predefinita di 1 GB non è sufficiente quando sono installati determinati carichi di lavoro. Tuttavia il completamento della compilazione con solo 1 GB di memoria potrebbe riuscire, a seconda dei requisiti di compilazione.
L'immagine finale è contrassegnata con il tag "buildtools:latest" in modo da poterla eseguire facilmente in un contenitore come "buildtools" perché il tag "latest" è l'impostazione predefinita se non viene specificato alcun tag. Se si vuole usare una versione specifica di Visual Studio Build Tools in uno scenario più avanzato, è invece possibile contrassegnare il contenitore con un numero di build specifico di Visual Studio e "più recente" in modo che i contenitori possano usare in modo coerente una versione specifica.
Uso dell'immagine compilata
Dopo avere creato un'immagine, è possibile eseguirla in un contenitore per eseguire compilazioni sia automatiche che interattive. L'esempio usa il prompt dei comandi per gli sviluppatori, in modo che la variabile PATH e altre variabili di ambiente siano già configurate.
Apri un prompt dei comandi.
Eseguire il contenitore per avviare un ambiente di PowerShell con tutte le variabili di ambiente per gli sviluppatori impostate:
docker run -it buildtools2019
docker run -it buildtools
Per usare questa immagine per il flusso di lavoro CI/CD è possibile pubblicarla nel proprio Registro Azure Container o in un altro registro Docker interno, in modo che i server possano semplicemente eseguirne il pull.
Nota
Se l'avvio del contenitore Docker non riesce, è probabile che si verifichi un problema di installazione di Visual Studio. È possibile aggiornare il Dockerfile per rimuovere il passaggio che chiama il comando batch di Visual Studio. In questo modo è possibile avviare il contenitore Docker e leggere i log degli errori di installazione.
Nel file Dockerfile rimuovere i C:\\BuildTools\\Common7\\Tools\\VsDevCmd.bat
parametri e &&
dal ENTRYPOINT
comando . Il comando dovrebbe ora essere ENTRYPOINT ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]
. Ricompilare quindi il Dockerfile ed eseguire il run
comando per accedere ai file del contenitore. Per individuare i log degli errori di installazione, passare alla $env:TEMP
directory e individuare il dd_setup_<timestamp>_errors.log
file.
Dopo aver identificato e risolto il problema di installazione, è possibile aggiungere nuovamente i C:\\BuildTools\\Common7\\Tools\\VsDevCmd.bat
parametri e &&
al ENTRYPOINT
comando e ricompilare il Dockerfile.
Per altre informazioni, vedere Risoluzione dei problemi relativi ai contenitori di Windows e Build Tools.
Risoluzione dei problemi relativi ai contenitori di Windows e Build Tools
Esistono alcuni problemi durante l'installazione di Visual Studio in un contenitore Docker.
Risolvere i problemi relativi ai contenitori di Windows
I problemi noti seguenti si verificano quando si installa Visual Studio Build Tools in un contenitore di Windows.
Passare
-m 2GB
(o più) durante la compilazione dell'immagine. Alcuni carichi di lavoro richiedono più memoria rispetto al valore predefinito di 1 GB durante l'installazione.Configurare Docker per l'uso di dischi più grandi rispetto all'impostazione predefinita di 20 GB.
Passare
--norestart
sulla riga di comando. Alla data di redazione di questo articolo, qualsiasi tentativo di riavviare un contenitore di Windows dall'interno del contenitore restituisceERROR_TOO_MANY_OPEN_FILES
all'host.Se si basa l'immagine direttamente su mcr.microsoft.com/windows/servercore, .NET Framework potrebbe non essere installato correttamente e non viene indicato alcun errore di installazione. Il codice gestito potrebbe non essere eseguito dopo il completamento dell'installazione. Basare invece l'immagine su microsoft/dotnet-framework:4.7.1 o versione successiva. Ad esempio, durante la compilazione con MSBuild potrebbe essere visualizzato un errore simile al seguente:
C:\BuildTools\MSBuild\15.0\bin\Roslyn\Microsoft.CSharp.Core.targets(84,5): errore MSB6003: non è stato possibile eseguire l'eseguibile dell'attività specificato "csc.exe". Impossibile caricare il file o l'assembly 'System.IO.FileSystem, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' o una delle relative dipendenze. Non è possibile trovare il file specificato.
Risolvere i problemi relativi ai contenitori degli strumenti di compilazione
Potrebbero verificarsi i seguenti problemi noti quando si usa un contenitore di Build Tools. Per verificare se i problemi sono stati risolti o se sono presenti altri problemi noti, visitare Developer Community.
- IntelliTrace potrebbe non funzionare in alcuni scenari all'interno di un contenitore.
- Nelle versioni precedenti di Docker per Windows, le dimensioni dell'immagine del contenitore predefinite sono solo di 20 GB e non saranno abbastanza per Build Tools. Seguire le istruzioni per modificare le dimensioni dell'immagine specificando minimo 127 GB.
Per verificare un problema di spazio su disco, controllare i file di log per altre informazioni. Se
vslogs\dd_setup_<timestamp>_errors.log
si esaurisce lo spazio su disco, il file includerà quanto segue:
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.