Upgrade to VS2010
It’s been exactly 11² days since Microsoft released Visual Studio 2010. Of course the fearless developer downloaded and installed every CTP and Beta version in the very millisecond it was available, but some places (i.e. work) don’t really welcome these additional adventures and productivity fluctuations.
However, with the official release out for some time, we carefully upgraded our fairly large C# codebase from VS2008 to VS2010. Here’s what we had in mind:
- upgrade our codebase to VS2010
- still have it work with VS2008 so not everyone on the team is forced to upgrade at the same time
- keep it simple (files) to avoid any crazy scm branching/merging/scripting
- keep the codebase at .NET 3.5, without upgrading to .NET 4.0
Don’t let your first date with the VS2010 migration assistent (wizard?) ruin your high hopes for the above. Try it, have a look at the result (including but not limited to)
- re-auto-generated code (designer files, proxies, etc.), including new fxcop violations if you’re lucky ;)
- a couple of new migration files, logs and reports
- new sections in project files (bootstrapping and whatnot..)
… and then revert these changes and fire up your favorite editor. All you really need to do to make your project files open with both VS2008 and VS2010 is
1 Change the ToolsVersion
Change the ToolsVersion
attribute in the <Project/>
element from 3.5
to 4.0
.
2 Change the OldToolsVersion
Change the <OldToolsVersion/>
element from 2.0
to 3.5
3 Conditional import of WebApplication.targets
If you have a WebApplication project, you need to create a conditional import for the Microsoft.WebApplication.targets
in order to support both paths:
And that’s it. Your projects should open without any problems or migration wizard interruptions in both versions of Visual Studio. However, when you compile with VS2008 you will encounter the following warning
Project file contains ToolsVersion=”4.0”, which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion=”3.5”.
This is obviously completely harmless and will not affect your build.
4 Create a separate solution file
Unfortunately we did not find a way to make solution files play in both studios so we ended up creating separate files
Super.Clever.Service.sln
Super.Clever.Service.vs2010.sln
Overall it was a very smooth transition where some team members didn’t even notice that some of us were already using VS2010 :)