3

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.

Improve this question
3
  • 5
    Why not install VS 2017 on every workstation (in parallel to VS 2013), but keep working with the VS 2013 toolset (using VS 2017) until all workstations are updated? Then you can gradually migrate the applications to the new toolset. Then there will be noone who "can not work because they are working on VS 2013", as you wrote. – Doc Brown Nov 15 '17 at 6:50
  • 2
    I dislike the approach of changing filenames to indicate the development environment, as a principle - it forces your update procedures for the next version of VS, or even worse those 2017 names persist longer than VS2017. You're already on Git, so you should be able to create a pair of branches and update both those to 2017 without interfering with anyone else. I would suggest requiring everyone to pull updates and commit/push their current work at a certain moment, perhaps 5 PM next Wednesday, so you can have a fairly up-to-date and working codebase that you can begin your work on. – user3685427 Nov 15 '17 at 19:24
  • @DocBrown We did the approach you suggested and it worked nicely. I would recommend it too! – T. Sar Nov 16 '17 at 17:11
2

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.

Improve this answer
3
  • 1
    I fail to grasp #2 : If OP does the transition successfully on his machine and checks that in to a dedicated branch, this branch can be checked out and tested. Once this is done, all the procedure left is for devs to switch branches / or merge the branch up to master. No manual procedure is needed. – Martin Ba Nov 15 '17 at 8:43
  • @MartinBa If dependencies change as OP claims it may, it isn't as simple as updating the project unless the libraries themselves are saved in git (your 3rd party precompiled dependencies as you wrote yourself in your answer). It may also involve adding a network drive with the new dependencies or whatnot. There may be a configuration change as well, something that may vary from user to user but is a mandatory configuration value to provide in the new version. #2 covers everything that isn't simply "update all" from git. – Neil Nov 15 '17 at 9:43
  • Ah ok. Well. Ideally there shouldn't be any but some trivialities in #2, but I guess there's a whole range of possibilities in practise. :-) Installing VS2017 on all dev machines would fall under #2 too. – Martin Ba Nov 15 '17 at 12:27
4

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.

Improve this answer
4

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.