Stuck on an older toolset version? Move to Visual Studio 2017 without upgrading your toolset
⏱ Updated on March 11, 2019 with the latest functionality in Visual Studio 2017
Are you currently developing your C++ projects in an older version of Visual Studio? If your reasons for avoiding the all-new features in VS 2017 are covered next, then read on: this post may have good news for you.
Help! I am stuck!
There are many reasons why you may want to use Visual Studio 2017 in your day-to-day job. Just to name a few:
- New lightweight installation experience and git integration
- Enhanced “Find all References” and new “Go to” experiences for fast code navigation
- New C++ refactoring capabilities and Predictive IntelliSense
- New Diagnostics tools debugger window and Error List window
- Revamped breakpoints, exceptions window, exception helper and new PerfTips
- New extensions like the C++ Quick fixes or the 2017 Productivity Power Tools.
- Are your binaries tied to an older version of CRT that for maintenance reasons you can’t upgrade?
- Are you dependent on older (non-conformant) language constructs that would break if you move to a more recent compiler?
- Are you relying on 3rd party libraries compiled with a specific version of the VC toolset?
- Are you exposing C++ APIs for other parties to consume, so you’re restricted to a specific version of the C++ compiler & CRT?
If these cover your reasons for not using VS 2017, I’m going to let you in on a little secret: you can start using Visual Studio 2017 today without having to change your toolset version (i.e. the current compiler and the matching target CRT).
Well, it’s not really a secret that Visual Studio supports native multi-targeting and round-tripping. And we definitely want to shine more light on it:
Native multi-targeting is the ability of the latest IDE to build using toolsets installed by previous versions of Visual Studio (VS 2008 and up).
Round-tripping is the ability of the latest IDE to load projects created by a previous IDE version without making any changes to the project assets (VS 2010 projects and up), thus allowing it to load back in the previous IDE too.
Using these features means that you will be taking advantage of the latest IDE features in VS 2017 without also taking advantage of the latest advances in the C++ compiler, libraries and build tools (e.g. build throughput). Disclaimer: there are IDE features that also depend on the latest toolset capabilities and they will be incompatible with older toolsets: e.g. type information will be missing in the Memory Profiler, and the refactoring operation “Convert to Raw string literals” will generate C++11-compliant code, making it not compile with VS 2012 compilers and older.
Say again? How does Native retargeting work?
Taking advantage of native multi-targeting is as simple as installing Visual Studio 2017 side-by-side with your older Visual Studio version, then opening your existing project in VS 2017.
During project load, you will receive a prompt on whether you want to upgrade to the latest C++ toolset shipping with VS 2017. Since you want to stay with the older compiler and libraries version, you should decline by hitting the “Cancel” button – you can always upgrade later too if you choose to experiment with the latest C++ toolset.
Now every time you build in VS 2017, the binaries that get generated are fully compatible with the ones you were previously building in your older version, e.g. VS2010. That’s because behind the scenes, VS 2017 delegates the build to the same C++ compiler and consumes the same libraries that your older IDE ships with.
A new dilemma: should I let my team know? About project round-tripping
Because you chose not to upgrade your project, VS 2017 doesn’t make any changes to your project or solution. So the fact that you’re using VS 2017 in your day-to-day work might as well be your little secret – the rest of your team will continue to use the older version without any clue that you’ve upgraded. It’s kind of a big secret since your colleagues won’t know how you suddenly increased your productivity so much!
So, can you really keep this a secret? Once the cat is out of the bag, everyone could be using VS 2017 around the office — our whole team here in Redmond agrees that’s a good thing (and… we’re not biased at all)
PS: What you’ll notice is that everyone in the team will see the same upgrade prompt the first time they load the project in VS 2017. So if you want to avoid an accidental pull request that upgrades all your projects coming from the enthusiastic junior member in the office down the hall, you can inhibit the upgrade prompt completely before spreading the news by following the instructions in this document: “Disable project upgrade“.
What about Visual Studio 2008?
Visual Studio 2008 had its own dedicated build system for C++ called VCBuild. With VS 2010, C++ moved to MSBuild so because of this change, to get your VS 2008 projects building in VS 2017 requires a bit more work. The end result will be similar as above: you will be using the VS 2017 IDE and generate binaries that are fully compatible with binaries created from the VS 2008 IDE.
First, in addition to installing VS 2017 you also need to install VS 2010 on the same machine with your VS 2008. This ensures that the appropriate MSBuild scripts that enable targeting VS 2008 are installed (they only ship with VS 2010).
Second, you will need to put your VS 2008 solution and projects through the upgrade process. When you get the below upgrade prompt, please review the information presented.
Now is also a good time to create a backup copy of your VS 2008 .sln file as it will get overwritten by the VS 2017 .sln file (if you’re only experimenting with VS 2017, maybe you may even want to upgrade the backup copy instead of the master copy under source control). When you click “OK”, the wizard will create VC project files with a new extension (.vcxproj) side-by-side with the existing .vcproj files, so as long as you’re taking care of the .sln file, the upgrade will be impact-free for your existing VS 2008 projects.
When the upgrade completes, you will get an upgrade log report. If there are any errors or warnings for any of your projects, you should review the log carefully and make sure that you acknowledge the changes presented and follow up on any action items listed there. For more information on the upgrade log report check out the C++ Project Upgrade Guide.
Now that the project upgrade is complete, your project actually targets the VS 2017 latest toolset. You need to go back to VS 2008 as a last step: open the project properties (right click in Solution Explorer on the project and select Properties) and under General, change Platform Toolset to “Visual Studio 2008 (v90)” instead of “Visual Studio 2017 (v141)”.
After this change, the binaries built by VS 2017 will be built using the same VS 2008 compiler and libraries as the ones building inside the VS 2008 IDE.
While we’d like to see all of you using the latest C++ toolset too, we know that migrating your code and dependencies takes time and depending on where you are in your project lifecycle, it can add too much risk. However, we hope you find this refresher on native multi-targeting and round-tripping of C++ projects useful, and a good reminder that this shouldn’t hold you back from taking advantage of the IDE improvements in the latest Visual Studio IDE.
To wrap things up, here it is – the link to download Visual Studio 2017. << Click right here!
Is there anything else holding you back? We want to know what other reasons may block you from upgrading today. Let us know by adding your comments below or by contacting us directly at firstname.lastname@example.org for a more detailed conversation.