How can I painlessly upgrade my team's codebase to Visual Studio 2017?

Question

So our team has products that currently runs on Visual Studio 2013. Now we want to move to Visual Studio 2017. So I've been assigned the task to make the transition to Visual Studio 2017 as painless as possible.

Here is the list of challenges that this task presents

• We use git as our versioning system and we have all of our updated code on a master branch (including .vcxproj files). Therefore updating would change these files. If these files are changed the rest of my team who are constantly maintaining and adding new features can not work because they are working on VS 2013
• We have another repo for our 3rdParty libraries which all need to be updated too to match up with the VS 2017 toolsets. So if I update the 3rdParty Libraries too, it would be the same problem as the first

Question:

I have viable option that I can think of. But, I'm looking to see if anyone has a better idea.

Here is what I'm thinking

• Make a separate 3rdParty folder with all the updated 3rdParty Libraries in it
• Once I've trasferred the products in 2017 I will take all the *.vcxproj and *.sln files make them all look like this *2017.vcxproj and *2017.sln files and push them to master

That way when it's time to transfer everyone in VS 2017. All they need to do is download the new 3rdPartyResource copy and click on the *2017.sln.

The reason why I'm looking for a better idea is because, I am not sure if this idea will work and I can only test if it works after I've put in all the work for it. I was hoping there is a more incremental steps that I can do to ensure I'm not breaking or slowing down anybody along the way. Anyone have a better idea?

If it helps here is what our software structure is like:

├───3rdPartyResource
│   ├───3rdPartyLib1
│   └───3rdPartyLib2
└───Software
    ├───DevelopmentTools
    │       DevelopmentProject1.v
    │       DevelopmentProject2.v
    │
    ├───Libraries
    │       Library1.vcxproj
    │       Library2.vcxproj
    │
    └───Products
            Product1.vcxproj
            Product2.vcxproj

More Information Our code base is in C++ and we strictly use static libs only (I didn't decide this). This is just how our team does it.

Answer 1

To simplify your task, you must guarantee two things:

1. The project compiles and works properly in VS2017.
2. Write a procedure for upgrading to VS2017 in preferably steps that any of your colleagues could follow (both in simplicity and resources necessary).

Step #1 is fairly straightforward and what will take the most "work". Ideally you would create a branch so you can still commit without creating problems for others. Keep track of the changes you make to the project that can't be resolved simply by updating the code from git as it will come in handy later.

Verify that it works and perhaps even have it okayed by your boss (nothing worse than finding out later that you created problems because some aspect of the program was overlooked). Okay, at this point, you're ready for step #2.

Step #2 is a lot more subtle but equally important. It isn't enough that it works for you. It has to work for everyone, and having it work for you is no guarantee. Therefore you should write a procedure for updating using the information you learned during your updates of all the extra steps you had to perform in addition to code changes.

Once you have the procedure and you're confident in it, delete, yes, delete your project and start fresh with the version that your companions are using from trunk. Follow your own procedure to get to point B on your branch (altering the procedure only to compensate for the fact that your code is still on the branch and not in trunk). Everything should work as expected, and until that is the case, you have work to do until issues are resolved or the procedure is altered.

Only now can you push the changes to trunk. Make sure your colleagues know the date. Ideally you would get an opportunity to perform a last check using your own procedure to ensure everything works as expected.

Answer 2

It may be a viable option to branch off a "legacy master" in git for those still using 2013. This is especially good since you know that the branch will eventually be closed, as everyone has moved to 2017 (forever alive git branches aren't a good thing).

This way you can concentrate on the master branch for any new work using 2017, but anyone still in the middle of work can stay on the legacy branch, and have their changes merged/cherry-picked to master. This of course requires backporting changes from master to legacy too, so you have an incentive to transition as quickly as possible.

Answer 3

At our site, we maintain a range of projects over VS2010 and VS2015 (concurrently). This works OK, obviously you have to double compile stuff and make sure the VS2010 compiler doesn't cough on any newer C++ constructs, but so far it works.

• Before you can start rolling out any 2017 changes, every developer should have VS2017 installed. Possibly do this at the very beginning, so any incompatibilities between having VS2013 and VS2017 installed side by side can be ironed out as you go along. (I don't expect many.)
• Best thing would be to start with some refactorings on the 2013 side to make things go smoothly afterwards:
  • You should put all precompiled dependencies (3rd party) into a separate folder denoting the VS toolset (e.g. 3rdPartyResource\3rdPartyLib1\bin\vc120\lalala.lib)
  • 3rd party output folders and especially intermediate folders should all include the platform toolset, so that you can later compile VS2013 and VS2017 side-by-side for a smooth transition. (Final output folders of your apps don't really need this.)
  • Make sure your vcxproj settings are all cleaned up and aligned across platforms and debug/release settings. Possibly move common settings to .props files.

At least for us with VS2010 vs. VS2015, we can easily share vcxprojfiles - they only need a few changes to build on both. We have some simple manual customizations in the files to make this work well for us, e.g.:

bla.vcxproj -

...
<PropertyGroup Condition="'$(VisualStudioVersion)' == '10.0'">
    <OurPlatformToolset>v100</OurPlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(VisualStudioVersion)' == '14.0'">
    <OurPlatformToolset>v140</OurPlatformToolset>
</PropertyGroup>
<!-- Override hardcoded setting PlatformToolset with our version detected from VS -->
<PropertyGroup Label="Configuration">
  <PlatformToolset>$(OurPlatformToolset)</PlatformToolset>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />

All in all, a few macros go really far to make the vcxproj files compatible between studio versions -- and this is only necessary if you need to use them side by side for a period of time. Otherwise doing the changes on a separate branch and merging them back in when you want to transition might be a better idea anyway.