When we build Visual Studio Code, we do exactly this.
According to this comment from a Visual Studio Code maintainer: If you rely on nuget pack actions configured in your csproj file then you will need to also install that extra workload like so: Start-Process "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installer.exe" -ArgumentList 'modify -installPath "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools" -passive -add .Microsoft’s vscode source code is open source (MIT-licensed), but the product available for download (Visual Studio Code) is licensed under this not-FLOSS license and contains telemetry/tracking. In fact the entire Build Tools product seems like it is under heavy development as lots of new options are appearing in each release. It seems like the latest Build Tools bits no longer include the Nuget build targets (.BuildTools) by default. Note that above I have hard coded to the default install path of build tools so your mileage may vary. Invoke-webrequest -uri -OutFile c:\temp\vs_buildtools.exeĬ:\temp\vs_buildtools.exe update -wait -passive -norestart -installPath "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools" using the currently installed version of the bootstrapper seems to struggle to update itself first in all versions, so a fresh download is more reliable The following snippet of powershell will download the latest version of the VS 2017 build tools bootstrapper to a temp folder, and then use that to to actually update the build tools. The MS installer cli docs for this stuff are fairly comprehensive, but lacking coverage of just the build tool update scenario at the moment. Normally chocolatey does a great job of this for me, however scripted update of VS build tools using chocolatey does not seem to work. If you have to maintain a farm of build servers it can be a pain to keep them updated will the latest versions of all the tools needed, and if you have a few servers you will have scripts to automate this.
0 kommentar(er)
