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
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
*.slnfiles make them all look like this
*2017.slnfiles 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
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.