Working with both VS 2010 and 2008 on the team

4/20/2010 code

With any software version upgrade, there are those that upgrade on day 1, and can’t wait to get the beta bits of v.next, and there are those who wait-n-see, wait for a plugin to get upgraded, or just generally need some time to get comfortable with the change.  Upgrading to Visual Studio 2010 is no exception.

When you’ve got a team of people and certain people fall into each category, things can get interesting.  In this case, there are some specific steps we can take to facilitate both groups of users simultaneously working on the same code base.

Note that upgrading a solution from .net 3.5 to .net 4.0 is also a step to take, but you can’t use VS 2008 with .net 4.0, so you’ll need to wait for the entire team to upgrade for that.

Towards the end of using .net 3.5 simultaneouslyin both VS 2008 and VS 2010, the steps are pretty straight-forward.  Much like the adjustments for VS 2008 / VS 2005 compatibility, this is a pretty straight shot.  Here’s the steps I took.  I give it the official “works on my machine” seal of approval.

  1. Check in any changes to source control.  Make a backup.  Archive the machine.  Get comfortable with it.  If this fails, you’ll need it.  :)

  2. Fire up Visual Studio 2010, and run the project conversion wizard, insuring you keep the solution in .net 3.5.  It’ll add tons of gunk to each .csproj file and to the .sln file, and that’s fine.  Getting VS 2010 comfortable with the solution is the biggest leap, and it’s also usually the most automatic.

    With those done, the rest unfortunately is manual.

  3. The first major difference is at the top of the sln file.  A VS 2008 file has these 2 lines at the top:

    Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008

    A VS 2010 sln file has these 2 lines at the top:

    Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010

    That’s the only difference.  Unfortunately, you can’t exactly switch it back and forth locally.  Well, I guess you could, but someone someday will check it in the wrong way, and the build will go boom.  Bad news.

    Instead, my chosen solution is to copy the sln file and name the new one with a catchy suffix.  For example, if I have “mysln.sln”, I’ll name the new one “mysln-10.sln”.  Since we ran the project conversion wizard previously, we can copy the sln file to it’s new name, add that to source control, and revert the changes to the original (VS 2008-compatable) sln file.

    Periodically diff the files and/or invite the team to add / remove projects from both.  This happens so rarely that it doesn’t seem an issue.

  4. The next major difference is in Web Application Project .csproj files.  At the bottom, in the <Import ...> section, a VS 2008 project has this line:

    <Import Project="$(MSBuildExtensionsPath)MicrosoftVisualStudiov9.0WebApplicationsMicrosoft.WebApplication.targets" />

    A VS 2010 project has this line:

    <Import Project="$(MSBuildExtensionsPath32)MicrosoftVisualStudiov10.0WebApplicationsMicrosoft.WebApplication.targets" />

    MSBuild’s Condition statement comes in really handy here.  Change the line to these lines and it’ll work nicely for both:

    <Import Project="$(MSBuildExtensionsPath32)MicrosoftVisualStudiov10.0WebApplicationsMicrosoft.WebApplication.targets" Condition="'$(Solutions.VSVersion)' == '9.0'" />
<Import Project="$(MSBuildExtensionsPath32)MicrosoftVisualStudiov10.0WebApplicationsMicrosoft.WebApplication.targets" Condition="'$(Solutions.VSVersion)' == '10.0'" />
    1. The C++ project file is drastically different.  VS 2008 uses .vcproj files, VS 2010 uses MSBuild compatible .vcxproj files.  Unfortunately I find no good way to correlate the differences easily.  Here’s my solution of choice:

    – In the VS 2008 sln file, reference the .vcproj file.  In the VS 2010 sln file, reference the .vcxproj file.

    – When changing the project (adding/removing files), you gotta update both.  Yeah, I hate it too.

    – Managed code referencing C++ projects gets weird.  Inside the IDE, all you see is the project name, but in the .csproj file is the name of the C++ project file.  Therefore, if VS 2010 notices the vcproj reference, it’ll convert it, and when the build server sees the .vcxproj reference, it’ll die noting it doesn’t support that project type.  To get around it, I use conditionals here too:

    <ProjectReference Condition="'$(MSBuildToolsVersion)' == '3.5'" Include="pathtoproject.vcproj">
...
</ProjectReference>
<ProjectReference Condition="'$(MSBuildToolsVersion)' == '4.0'" Include="pathtoproject.vcxproj">
...
</ProjectReference>

    On the up-side, if you don’t have any native code, you can completely skip this step.

  5. Source control: We’ll see some new files appear in our solution when working with VS 2010.  Here’s how I handled them:

    – Commit the new VS 2010 .sln file, and the new VS 2010 .vcxproj files (if any)

    – Review the additions to .csproj files and web.config files.  You may deem some of the adjustments it made unnecessary (e.g. the big section about “previous tools version”).  After removing them, fire the solution back up in both VS 2010 and VS 2008 to see if either gripes or fires up the conversion wizard.  If it does, sadly, ya gotta leave the gunk in.

    – The .ncb and .openncb files are the C++ intelisense database.  Exclude them from the repository.  It’s like the .user files – it’ll change or get recreated as soon as you open the IDE.

That’s it.  Just a few simple steps and you can simultaneously use VS 2008 and VS 2010 on the same code base.  If you don’t have Web Application Projects or you don’t have C++ projects, it’s even easier.  And now each member of the team can use the tool that works best for them.

Unfortunately, those in VS 2010 can’t use the C# 4 conventions yet though.  Push the VS 2008 stragglers to upgrade, switch the solution to .net 4.0, and you’ll get a whole new love from your IDE.

[Update]: As a matter of “avoiding unnecessary commits to source control”, I removed all the additional tags VS 2010 added, including FileUpgradeFlags.  Thanks to Zuhaib (comment below) who pointed out this is the way to get VS 2010 to not keep doing an upgrade loop.  He noted that he had to put the V10.0 path before the V9.0 path as well, which I didn’t need to do.

[Update]: I’ve found more success matching the MSBuild version rather than the VSVersion in random spots.