Much has been written on the fact that Visual Studio 2008 can build .net 2.0 applications, and that they can be installed side-by-side on the same machine.  This is phenomenal as it allows organizations to upgrade developer tools without forcing clients to also upgrade .net framework versions.  Very nice.

However, what isn’t as fully documented is using Visual Studio 2008 and Visual Studio 2005 together on a development team.  For example, Sally Slickster is an early adopter, downloaded the VS 2008 iso from MSDN 8 minutes after Scott Guthrie posted the RTM news.  She’d like to use it for all development work from now on.  Harry Hard-head, on the other hand, just figured out where all the settings are in VS 2005, and installed VS 2005 SP 1 under great duress.  No way will he use VS 2008 until at least SP 1.  They’re both working on the same .net 2.0 project.

When converting a VS 2005 project to VS 2008, and leaving it to target .net 2.0, it only changes 2 sets of files: the solution file (*.sln) and the project file(s) (*.csproj).  Ok, technically, as VS 2008 developers do things, it’ll replace some comments with new version information.  The header at the top of .designer.cs files now reads version 2.0.50727.1433 for example.  Since these files are rebuilt any time the designer sneezes, I’ll ignore them.

The .sln files used by VS 2008 and VS 2005 are similar, but not compatible.  (So says my very un-scientific testing.)  Yes, get annoyed, get indignant, run the VS 2008 conversion wizard, leave the projects in .net 2.0 mode, then check in the second .sln file in source control.  I hate it too, but it could be worse.

The .csproj files are a different story.  During the VS 2008 conversion wizard, many new nodes and attributes are added to each project.  I didn’t find anything removed, just new stuff added.  With these in place, VS 2005 pulls up a “This project has been modified outside the designer” security warning box the first time the project is re-opened.  UAC has trained me to ignore these dialogs and just push OK.  Closing and reopening VS 2005 seems to not bring up the security dialog a second time.

The major headache with the .csproj files is with Web Application Projects.  This line is changed:

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

it becomes:

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

Note the ‘v8.0’ becomes a ‘v9.0’.

Well, now VS 2008 is happy, but VS 2005 users can’t build because C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0 doesn’t exist on their machines.

Adam Salvo suggests just copying this directory from a machine with VS 2008 on it to all the machines without it.  It’s a whopping 900k, so who cares.  Perhaps a carefully named shortcut could do the job as well.

Steven Harman suggests replacing the offending line in the .csproj file with these lines:

<Import Project="$(MSBuildExtensionsPath)MicrosoftVisualStudiov8.0WebApplicationsMicrosoft.WebApplication.targets" Condition="'$(Solutions.VSVersion)' == '8.0'"/>
<Import Project="$(MSBuildExtensionsPath)MicrosoftVisualStudiov9.0WebApplicationsMicrosoft.WebApplication.targets" Condition="'$(Solutions.VSVersion)' == '9.0'" />

Basically, tell it to use what ever works best.  Very nice.  Very clean.  Very self-contained.  Yes.

Perhaps in time, everyone will move to VS 2008 and this problem will just disappear.  In the mean time, now Sally and Harry are happy, and you know what happens when Harry met Sally…

Rob