Try out the latest C++ compiler toolset without waiting for the next update of Visual Studio

Andrew

February 16th, 2016

Updated 22 Apr 2016: The NuGet package is now being uploaded daily. The payload doesn’t change every day but you should see new bug fixes and/or feature updates every five days or so. See the blog post announcement here: https://blogs.msdn.microsoft.com/vcblog/2016/04/26/stay-up-to-date-with-the-visual-c-tools-on-nuget. Last November we announced a prerelease of the Visual C++ Build Tools, a standalone C++ installer for build environments. We asked you for feedback on the experience and truly appreciate the great response we got in blog comments and through other channels. We’ll be updating the VC++ Build Tools soon and will incorporate some of your suggestions with the update. [Updated Apr 2016: The Build Tools have officially released: https://blogs.msdn.microsoft.com/vcblog/2016/03/31/announcing-the-official-release-of-the-visual-c-build-tools-2015/] Some of you suggested that the VC++ Build Tools don’t go far enough toward creating a lightweight way to acquire the VC++ tools. Some folks asked for an install that works through xcopy. Others suggested we use a package manager, or even just a zip file. What’s clear from all your feedback is that many of you just want an easy way to try out the latest compiler inside Visual Studio. Today we’re announcing a new experiment: releasing the VC++ toolset as a NuGet package that can be added to any C++ project or solution targeting desktop. Installing this NuGet package lays down a new copy of the VC++ compiler, header files, and libraries. You can compile your code with this preview toolset and, once you’re done checking out the new tools, you can just uninstall the package and get back to the supported toolset installed with Visual Studio. Why might you want to try out new tools? There’s a lot of change happening in Visual C++ today: support for new features going into the C++ 17 language such as Coroutines, support for proposed features such as C++ Modules, and daily bug fixes for standards conformance. You shouldn’t have to wait for the next VS Update if you’re tracking our progress on new language features or have been waiting for a conformance fix. Installing a NuGet package is the quickest way to test a new compiler. The experience we’re offering through NuGet today is pretty limited: it’s just one big (226 MB) NuGet package that installs in a project or a solution. We’ve got ideas about how to make the experience better: machine-wide install, for example, or allowing you to select just one host or target architecture. We’re publishing the packages manually right now but would consider automating so we can do nightly updates if that would be useful for C++ developers. The NuGet package will install a compiler, headers, and libraries that override the current VS version but your project will continue to pick up the other libraries from your VS install. This package doesn’t include special-purpose libraries like ATL or MFC–those are only available through VS right now. And if you need a new version of the Windows libraries or Universal CRT you’ll have to install a new Windows Development Kit. We’d like you to try out the NuGet installer and send us feedback on where you’d like us to head with the project. You can leave comments on the blog, or send mail to us directly at VCNuGetTools@microsoft.com. This is a prerelease project so we can’t officially support it, but we’re happy to help out where possible.

For those of you who are familiar with using NuGet in Visual Studio, the server is located here: https://vcppdogfooding.azurewebsites.net/nuget. There’s only one package at the moment so just browse the feed and you’re sure to find it. If you need a more detailed walkthrough, read on. Right now you can only install the NuGet package locally in a project or solution. Just right-click on the project or solution and select Manage NuGet Packages. Because these packages aren’t located on NuGet.org you’ll have to set up a new Package Source. Click on the gear icon on the top right of the dialog: This will bring up the Options dialog open to Package Sources. Click on the + button add a new package. Once you’ve done this, you’ll have to edit the Name and Source on the bottom of the dialog. Enter any name you like, but make sure the source is http://vcppdogfooding.azurewebsites.net/nuget/. Hitting the OK button will close the dialog and bring you back to the NuGet package manager. Select your new Package Source at the top of the dialog and click on the Browse tab. Make sure to click the Include prerelease checkbox or you won’t see anything. Once the package manager connects to the server, you should see a package called VisualCppTools. Select it and click the Install button on the right. Click through the next few dialogs (making sure to carefully review the license on the second dialog) and your NuGet package will install. When you rebuild your project or solution you’ll be using the preview C++ toolset. Nothing else will have changed in the developer experience—IntelliSense, source browsing, debugging should all be the same. You’re just using new compilers and libraries. When you want to go back to the officially supported toolset that came with Visual Studio, just go back to the NuGet Package Manager dialog and select the Installed tab. There you’ll be able to uninstall the preview toolset entirely.

Are you using the VC++ Build Tools SKU? It’s a little more work for you to try out the preview toolset but it’s easily done. Here’s how you can do it. First, you need to get the NuGet command-line tool. Both the download link and documentation are at this link: https://docs.nuget.org/consume/command-line-reference. When you run nuget.exe you’ll need to supply a source parameter pointing to the server and the -Prerelease switch on any commands. Here’s the command to install the preview toolset (command shown in blue with output in black):

C:\tmp>nuget install VisualCppTools -source https://vcppdogfooding.azurewebsites.net/nuget/ -Prerelease Feeds used: https://vcppdogfooding.azurewebsites.net/nuget/ Attempting to gather dependencies information for package 'VisualCppTools.14.0.23811-Pre' with respect to project 'C:\tmp', targeting 'Any,Version=v0.0' Attempting to resolve dependencies for package 'VisualCppTools.14.0.23811-Pre' with DependencyBehavior 'Lowest' Resolving actions to install package 'VisualCppTools.14.0.23811-Pre' Resolved actions to install package 'VisualCppTools.14.0.23811-Pre' Adding package 'VisualCppTools.14.0.23811-Pre' to folder 'C:\tmp' Added package 'VisualCppTools.14.0.23811-Pre' to folder 'C:\tmp' Successfully installed 'VisualCppTools 14.0.23811-Pre' to C:\tmp'

Lastly, if you’re using the Visual C++ Build Tools Command Prompts, you’ll have to edit them to point to the preview’s install directory. The easiest way to do this is to edit the file vcbuildtools.bat that you’ll find in the same directory as the Build Tools Command Prompts. On my system, they’re at \Program Files (x86)\Microsoft Visual C++ Build Tools . If your Build Tools are installed there as well you’ll need to run your editor with Administrator privileges (e.g., search for Notepad, right click, and select Run as Administrator.) There’s a lot of fancy command script in that batch file but you only need to add one line. It overrides the VCInstallDir environment variable after the script pulls it out of the registry. Here’s the top of my file, customized to my install directory of c:\tmp , with the line I added in blue:

@echo off set curDir=%~dp0 @call :GetWindowsSdkDir @call :GetWindowsSdkExecutablePath32 @call :GetWindowsSdkExecutablePath64 @call :GetExtensionSdkDir @call :GetVCInstallDir @call :GetUniversalCRTSdkDir set VCInstallDir=C:\tmp\VisualCppTools.14.0.23811-Pre\lib

ative\ if not "%UniversalCRTSdkDir%" == "" @set UCRTContentRoot=%UniversalCRTSdkDir% if not exist "%~dp0..\MSBuild\Microsoft.Cpp\v4.0\v140\" goto error_no_VCTARGETS cd "%~dp0..\MSBuild\Microsoft.Cpp\v4.0\v140\" set VCTargetsPath=%cd%\ cd %curDir%

Note that you can’t just override VCInstallDir on the command line because the script builds other environment variables on top of VCInstallDir . And yes, it would be more efficient to stop setting the VCInstallDir environment variable when we’re just going to override it, but I’ll leave that as an exercise for the reader. After you’ve installed the package and edited your vcbuildtools.bat , running any of the Build Tools Command Prompts should result in the preview toolset being invoked. You can verify this easily by running cl -Bv to show the version of the compiler and the location from where it is running:

C:\Program Files (x86)\Microsoft Visual C++ Build Tools> cl -Bv Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23811 for x86 Copyright (C) Microsoft Corporation. All rights reserved. Compiler Passes: C:\tmp\VisualCppTools.14.0.23811-Pre\lib

ative\bin\cl.exe: Version 19.00.23811.0 C:\tmp\VisualCppTools.14.0.23811-Pre\lib

ative\bin\c1.dll: Version 19.00.23811.0 C:\tmp\VisualCppTools.14.0.23811-Pre\lib

ative\bin\c1xx.dll: Version 19.00.23811.0 C:\tmp\VisualCppTools.14.0.23811-Pre\lib

ative\bin\c2.dll: Version 19.00.23811.0 C:\tmp\VisualCppTools.14.0.23811-Pre\lib

ative\bin\link.exe: Version 14.00.23811.0 C:\tmp\VisualCppTools.14.0.23811-Pre\lib

ative\bin\mspdb140.dll: Version 14.00.23811.0 C:\tmp\VisualCppTools.14.0.23811-Pre\lib

ative\bin\1033\clui.dll: Version 19.00.23811.0 cl : Command line error D8003 : missing source filename

In closing

Please try out the tools and let us know what you think! We’re excited about where this project could go but we can’t do it without your ideas and suggestions on how you would use VC++ tools delivered through NuGet in your work or project. Please leave comments on this blog post or send us mail at VCNuGetTools@microsoft.com. Thank you!