Update 3 Mar ’17: A number of people have asked if a ZIP of our toolset is available. You might not realize it, but the NuGet format is just a ZIP file with an extra metadata file. If you download the current NuGet package and rename the file from .nuget to .zip you can open it in Windows Explorer. You’ll find our toolset under “lib\native”.
Update 3 Jan ’17: We’ve started to publish builds that match officially released versions of MSVC. For example, the VS 2017 RC build is on our NuGet server today. Just uncheck the “Prerelease” box to see the builds that match official versions. (Note that the NuGet distribution method is still prerelease and unsupported, but the tools match the ones distributed in VS.)
Update 9 Oct ’16: The daily C++ NuGet packages work with Visual Studio “15” Preview 5. We’re working on a new method of installing the latest daily toolset drop but for the time being, please continue to use the NuGet feed.
Do you want to try out the newest C++ compiler from Microsoft? Last February we announced a new way to install the Microsoft Visual C++ (MSVC) toolset. Instead of waiting for the next update of Visual Studio, you can just grab the latest release of MSVC from NuGet. Because the tools are being installed as a NuGet package in your project or solution you can easily uninstall the tools and get back to a production-quality environment. More details–and everything you need to know to install these tools–are in this blog post from February: Try out the latest C++ compiler toolset…
We heard two common pieces of feedback from our developer audience. First, you want more frequent releases of the MSVC toolset–nightly if possible. Second, you want better factoring: some of you want to install just x64-hosted tools, some want ATL/MFC, others explicitly don’t want ATL/MFC, and a few wish Clang/C2 was included.
I’m happy to announce that we’ve listened and are addressing both sets of requests. As of this week we’re updating the NuGet MSVC toolset every day. Just configure your NuGet Package Manager to add a new package source at https://vcppdogfooding.azurewebsites.net/nuget/, check the “Include prerelease” box, and browse for the VisualCppTools package. (More details on how to install this package, including instructions for installing on this package for use with the Visual C++ Build Tools, are available in : the February blog post.)
Now there are two important caveats that have to be mentioned here:
- First, the VisualCppTools package is prerelease software (read the EULA!) so it shouldn’t be used in production environments. We put this package out there so that you can try out new features in development or check to see if a bug has been fixed.
- Second, while we’re updating the package every day (around 1:30 PST, after our Packaging Bot has had lunch) not every day’s update includes new functionality. Our teams work in feature branches and integrate their work into the release branch periodically. We’ve been working on increasing the frequency of integrations but it’s currently about every 10-14 days. This means that any given day you might see new functionality (or new bugs!) from a compiler and libraries integration or from an optimizer/parser integration. But most days you’ll just see what you saw yesterday with a new timestamp on the binaries. If you do run into any new bugs with these tools–that is, regressions from the previous release of MSVC with Visual Studio–please send us feedback through Connect, email, or any of the usual channels.
What about the second request, better factoring of the MSVC tools? We’re hard at work on that problem too. But instead of pushing that work into the NuGet release channel, we’re focusing on making the Visual Studio “15” experience better. If you haven’t heard, we’ve got a fantastic new lightweight install experience that will install a just the parts of VS that you need. You can read more about the C++-only experience in this blog post: Lightweight C++ Installation in VS “15”.
Lastly, how do you know if you’ve installed successfully and are using the latest MSVC toolset? It’s easy! Just turn off the “Suppress Startup Banner” option in your C++ project configuration.
When you compile you’ll see the version number in the Output window. (MSVC Version 19.00.23918 corresponds to Visual Studio 2015 Update 2.) If you want to determine the version programmatically, just use the _MSC_FULL_VER predefined macro. Here’s what it looks like when I move a project from today’s NuGet MSVC tools back to the VS 2015 Update 2 toolset:
Above, compiled with the NuGet MSVC tools. Below, back to the Update 2 toolset.
Please try out the tools and let us know what you think! And make sure to let us know if you encounter any behavior that you consider a regression from the previous release of MSVC with Visual Studio or a released VS update. You can leave comments on this blog post or send us mail at VCNuGetTools@microsoft.com. Thank you!
This is awesome news for people reporting toolchain bugs. Thank you!
I’ve rewritten the property sheet that comes with these releases. The new property sheet works correctly with ATL/MFC and with Clang/C2, and has more correct behavior regarding `UseNativeEnvironment`. Just overwrite the VisualCppTools.props file that comes with the package and add the property sheet to your project *at the top* of the Property Manager window, or *at the end* of your project file if doing it manually.
https://gist.github.com/dodheim/d79bdbc1c0865313ea5c25c52e1fea29
Oh, and this also allows one to use the prerelease tools to build windows store/universal windows apps.
It would be more nicer, if you could also ship DLL runtime libs for convenience /MD build?
@ildjarn,
Thanks for your feedback.
We were using old props file that targeted only Windows Desktop development. We will update the props file to build for ATL/MFC and along with Clang/C2. We will also fix the correct behavior of ‘UseNativeEnvironment’.
@kangjoni, Thanks for the feedback.
Import lib – vcruntime.lib is already part of the package.
The ucrt.lib is provided by windows SDK so we have not included in the package here.
But we will consider your suggestion when we refactor this package.
I think what he means is the actual DLL files. The ones that we normally find in the redist directory.
@ We are planning to refactor the Nuget package to minimize its size and split into multiple packages for a specific scenario. When those packages before online, redist dlls will also be available as a package.
Thank you, I will certainly wait for this. Static vs runtime is not my option now . I have legacy c99 library for mingw to work with vs2015. Therefore, /MD builds is the only way for better compatibility. You could also provide readme file for DLLs runtime with certain “best match” cl.exe update version to work with.
Added redist runtime dlls.
It’s great to have possibility to try out the latest features! I have a suggestion though:
– Allow installing different compiler versions (for example: “Update 1”, “Update 2”, “Daily”) side by side in _same_ VS version
– Please allow _explicit_ selecting compiler version to be used for the build.
The reason is that we have to do our production builds with a certain version (in our case “Update 1”) because of binary compatibility for patching. Therefore I am not able to install the latest compiler versions on my machine and have to use a VM for it, which is a real pain.
1) Download the nuget package and rename it to have a .zip extension. E.g. today’s package from http://vcppdogfooding.azurewebsites.net/api/v2/package/visualcpptools/14.0.24026-pre downloads as VisualCppTools.14.0.24026-Pre.nupkg, rename this to VisualCppTools.14.0.24026-Pre.zip
2) Extract the zip somewhere
3) Add the property sheet in [extractionlocation]\build\native to your project. I recommend using the property sheet I posted a link to in a comment above instead of the one that comes with the package, as it is more functionally “correct” in every respect.
Now you have both compiler versions side-by-side, and only have to use or not use the property sheet to switch between them.
Thanks for the suggestion. We’ve thought about having different feeds. I’ll look into it.
This is great thanks.
What’s the version of Clang? Will Clang be updated (with upstream) regularly too?
The currently released version is 3.7, but they did say that they would be moving to 3.8 with the next update.
The Clang/C2 compiler is shipped about every 6 weeks. It gets built in a different tree so there’s no simple way to include it with these packages.
The VisualCppTools.props that comes with 19.00.24111+ is broken; apparently it relies on changes to core MSBuild property sheets that are not yet released to the public. The end result is that you will silently use your normal toolset installation instead of the daily build compiler/headers/libs.
I’ll again promote my own reimplementation of the property sheet here; it works correctly with Clang/C2 and Intel C++ Compiler, and with MFC/ATL apps; can be used to build Universal Windows/Store apps; and correctly respects `UseNativeEnvironment`.
Link: https://gist.github.com/dodheim/d79bdbc1c0865313ea5c25c52e1fea29
It should work with Dev14 Update U2 which is the current released VS version. Which version of VS are you using?
I meant the new props should work with VS 2015 Update 2 and beyond.
In both 19.00.24111 and 19.00.24112, VisualCppTools.props is setting things like `VC_ReferencesPath_VC_x86`, `VC_LibraryPath_ATL_x64`, etc, but it’s never setting `ReferencePath`, `LibraryPath`, etc, and nothing in the base MSBuild property sheets reads new elements. The file got a drastic overhaul from the markup in 19.00.24110 and prior – I’ve been watching. ;-] The original copy was flawed, but basically worked (ignoring Clang/C2); the new one simply never sets `ExecutablePath` et al, so the base installation toolset is used (Update 2 (19.00.23918) in my case, yes). I.e., things *appear* to work if you’re not explicitly using features of the new build, since you will get a clean compile. However, if you turn on diagnostic mode in MSBuild or compile with /Bv, it becomes obvious which compiler you’re actually executing.
If it matters, I am not using NuGet – I am extracting the package and adding the VisualCppTools.props sheet to my project by hand.
The new props file is based on recent refactoring(2015 Update2) on some of the common props files. If you are using VS 2015 Update 2 (or Update 3 CTP), it is just sufficient to override those variables in the new props file. “ExecutablePath” will be automatically taken care. The new props file will not work if you are using VS 2015 Update 1 or before. Additionally we just intend to support only desktop development for these Nuget packages ie) No store development until we deliver new refactored packages.
I would like to know which version of VS are you using?
Please mail me at iyyappam at microsoft dot com for further discussion.
Thanks for your feedback.
I tried this on a couple of solutions and the first time I got *five* copies of cl.exe installed when I would have expected six. The x86_amd64 version was missing, and it turns out we need that one. This was on May 9th.
Any idea what happened? When I tried again today I got all six copies, so that’s good.
To be clear, the VisualCppTools.14.0.24109-Pre package contained five copies of cl.exe, but the VisualCppTools.14.0.24112-Pre package contained the expected six copies. Bug in the 24109 package?
Yes, some of the previous packages didn’t contain x86_amd64 version of files which has been fixed now.
Looks like the concurrent_unordered containers are busted at least as of 24119 if _ITERATOR_DEBUG_LEVEL isn’t 0:
1>packages\visualcpptools.14.0.24119-pre\lib\native\include\forward_list(183): error C2039: ‘_Before_head’: is not a member of ‘Concurrency::details::_Split_order_list_value’
1> with
1> [
1> _Element_type=unsigned long,
1> _Element_allocator_type=std::allocator
1> ] (compiling source file WorkerClass.cpp)
1> packages\visualcpptools.14.0.24119-pre\lib\native\include\internal_split_ordered_list.h(358): note: see declaration of ‘Concurrency::details::_Split_order_list_value’
1> with
1> [
1> _Element_type=unsigned long,
1> _Element_allocator_type=std::allocator
1> ] (compiling source file WorkerClass.cpp)
1> packages\visualcpptools.14.0.24119-pre\lib\native\include\forward_list(178): note: while compiling class template member function ‘const unsigned long &std::_Flist_const_iterator<Concurrency::details::_Split_order_list_value>::operator *(void) const’
1> with
1> [
1> _Element_type=unsigned long,
1> _Element_allocator_type=std::allocator
1> ] (compiling source file WorkerClass.cpp)
1> packages\visualcpptools.14.0.24119-pre\lib\native\include\forward_list(301): note: see reference to function template instantiation ‘const unsigned long &std::_Flist_const_iterator<Concurrency::details::_Split_order_list_value>::operator *(void) const’ being compiled
1> with
1> [
1> _Element_type=unsigned long,
1> _Element_allocator_type=std::allocator
1> ] (compiling source file WorkerClass.cpp)
1> packages\visualcpptools.14.0.24119-pre\lib\native\include\internal_split_ordered_list.h(31): note: see reference to class template instantiation ‘std::_Flist_const_iterator<Concurrency::details::_Split_order_list_value>’ being compiled
1> with
1> [
1> _Element_type=unsigned long,
1> _Element_allocator_type=std::allocator
1> ] (compiling source file WorkerClass.cpp)
1> packages\visualcpptools.14.0.24119-pre\lib\native\include\utility(242): note: see reference to class template instantiation ‘Concurrency::details::_Solist_const_iterator<Concurrency::details::_Split_order_list_value>’ being compiled
1> with
1> [
1> _Element_type=unsigned long,
1> _Element_allocator_type=std::allocator
1> ] (compiling source file WorkerClass.cpp)
1> workerclass.cpp(60): note: see reference to class template instantiation ‘std::pair<Concurrency::details::_Solist_const_iterator<Concurrency::details::_Split_order_list_value>,bool>’ being compiled
1> with
1> [
1> _Element_type=unsigned long,
1> _Element_allocator_type=std::allocator
1> ]
1>
Which is the result of a change in _Flist_const_iterator’s operator*() to be
|| this->_Ptr == _Mycont->_Before_head())
From:
|| this->_Ptr
== (_Nodeptr)&((_Mylist *)this->_Getcont())->_Myhead)
(_Flist_const_iterator is likely correct in the change, it’s just an accidental consequence)
This has been fixed, thanks.
Unrelated but “related” (in that it’s related to pointer_traits work and unfancification), this no longer compiles:
#include
#include
#include
class A
{
public:
~A() { }
};
int main()
{
std::list x(1);
A* pa = static_cast(::operator new(1 * sizeof(A)));
std::uninitialized_copy(x.begin(), x.end(), stdext::make_checked_array_iterator(pa, 1));
pa->~A();
::operator delete(pa);
}
1>packages\visualcpptools.14.0.24124-pre\lib\native\include\xmemory0(290): error C2300: ‘A’: class does not have a destructor called ‘~_Ty’
1> packages\visualcpptools.14.0.24124-pre\lib\native\include\xmemory0(1125): note: see reference to function template instantiation ‘void std::_Destroy(_Ptrty)’ being compiled
1> with
1> [
1> _FwdIt=stdext::checked_array_iterator,
1> _Ptrty=stdext::checked_array_iterator
1> ]
1> packages\visualcpptools.14.0.24124-pre\lib\native\include\xmemory0(1139): note: see reference to function template instantiation ‘void std::_Destroy_range1(_FwdIt,_FwdIt,std::false_type)’ being compiled
1> with
1> [
1> _FwdIt=stdext::checked_array_iterator
1> ]
1> packages\visualcpptools.14.0.24124-pre\lib\native\include\xmemory(54): note: see reference to function template instantiation ‘void std::_Destroy_range(_FwdIt,_FwdIt)’ being compiled
1> with
1> [
1> _FwdIt=stdext::checked_array_iterator
1> ]
1> packages\visualcpptools.14.0.24124-pre\lib\native\include\xmemory(75): note: see reference to function template instantiation ‘_FwdIt std::_Uninitialized_copy_unchecked1(_InIt,_InIt,_FwdIt,std::_General_ptr_iterator_tag)’ being compiled
1> with
1> [
1> _FwdIt=stdext::checked_array_iterator,
1> _InIt=std::_List_unchecked_iterator<std::_List_val<std::_List_simple_types>>
1> ]
1> packages\visualcpptools.14.0.24124-pre\lib\native\include\xmemory(84): note: see reference to function template instantiation ‘_FwdIt std::_Uninitialized_copy_unchecked(_InIt,_InIt,_FwdIt)’ being compiled
1> with
1> [
1> _FwdIt=stdext::checked_array_iterator,
1> _InIt=std::_List_unchecked_iterator<std::_List_val<std::_List_simple_types>>,
1> _Iter=stdext::checked_array_iterator
1> ]
1> packages\visualcpptools.14.0.24124-pre\lib\native\include\xmemory(105): note: see reference to function template instantiation ‘_FwdIt std::_Uninitialized_copy1<std::_List_unchecked_iterator<std::_List_val<std::_List_simple_types>>,_FwdIt>(_InIt,_InIt,_FwdIt,std::input_iterator_tag,std::forward_iterator_tag)’ being compiled
1> with
1> [
1> _FwdIt=stdext::checked_array_iterator,
1> _InIt=std::_List_unchecked_iterator<std::_List_val<std::_List_simple_types>>
1> ]
1> test.cpp(16): note: see reference to function template instantiation ‘_FwdIt std::uninitialized_copy<std::_List_iterator<std::_List_val<std::_List_simple_types>>,stdext::checked_array_iterator>(_InIt,_InIt,_FwdIt)’ being compiled
1> with
1> [
1> _FwdIt=stdext::checked_array_iterator,
1> _InIt=std::_List_iterator<std::_List_val<std::_List_simple_types>>
1> ]
1>
Include iterator, list, memory. the list contains elements of type A. Likely nothing else of “importance” was “lost”.
There’s also a class to support some… old code… that has a conversion operator to pointer of array of char, like so:
using thing1 = unsigned char[20];
class A
{
operator const thing1* () const;
thing1 data;
};
A::operator const thing1* () const
{
return &data;
}
This isn’t compiling anymore when the function is declared out-of-line.
cl.exe /c conversion_test.cc
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24118 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
conversion_test.cc
conversion_test.cc(10): error C2738: ‘operator thing1 (*)’: is ambiguous or is not a member of ‘A’
conversion_test.cc(5): note: see declaration of ‘A’
conversion_test.cc(11): error C2270: ‘$S1’: modifiers not allowed on nonmember functions
conversion_test.cc(11): error C4430: missing type specifier – int assumed. Note: C++ does not support default-int
conversion_test.cc(12): error C2065: ‘data’: undeclared identifier
(explicit_test because I thought it may have had something to do with it being explicit or not,
Sorry for ending on an incomplete thought, I started writing it, and realized it was silly to have the explanatory text when I can just fix up the filename, so you can just ignore the ending parenthetical comment.
@ Michael, we are aware of this issue and will be fixed for Update 3.
Excellent, thank you!
I’ve been trying this out over the last couple days, and it’s been very hit & miss over whether I can actually download the tools from my CI script.
Powershell:
iwr https://dist.nuget.org/win-x86-commandline/latest/nuget.exe -OutFile nuget.exe
.\nuget.exe list “http://vcppdogfooding.azurewebsites.net/nuget” -prerelease
…comes back with “No packages found” and installing VisualCppTools returns “Unable to find package…”
Adam,
Thanks for the note. We’ve had some trouble lately with the Task Scheduler jobs that are uploading the package. We just uploaded one by hand now so there should be a package there.
Thanks,
Andrew
It seems the NuGet feed has not been updated for a while – the latest version I see is 2017-04-24T18:16:44Z (14.0.25224-Pre).
Is the updating process currently disabled or not working? Maybe the blog post could be updated if so.
At a guess, it wasn’t updated for VS2017 (MSVC toolchain 14.1), and they’ve stopped committing things to the VS2015 (MSVC toolchain 14.0) tree.
We’ve had trouble with the NuGet server that we’ve been hosting ourselves. We’re getting it corrected. Look for an update in the near future.