This is a “notepad” type post – I’m writing it as I go along, and I may write up the conclusions later on as a full article for one of the other web sites. However, the plan is to investigate how best to work in an environment where both VS2005 and VS2008 exist.
Environment under consideration
VS2005 has taken a long time to penetrate the market. I believe this is for three main reasons:
- Using VS2005 means using .NET 2.0, which means a deployment headache
- Using VS2005 means upgrading projects and solutions in a largely “magical” way
- It is impossible to use a VS2005 project/solution with VS2003
VS2008 reduces all of these problems:
- VS2008 can target .NET 2.0, 3.0 or 3.5; if you don’t need LINQ, WPF etc, you can just target the same platform as you did with VS2005.
- The changes between VS2005 projects/solutions and VS2008 ones is minimal, and easily verifiable. (For a start, you can easily do a diff – something which wasn’t feasible from VS2003 to VS2005.)
- It is possible to share projects between VS2005 and VS2008, even if different solution files are required.
In many cases it’s desirable to have a few developers trying out a new tool before a whole company decides to move over to it. In this case, I’m going to imagine I’m working at a company which is considering using VS2008, but wants to try it for a while first. It has many VS2005 projects/solutions, and the “bleeding edge” developers have to be able to develop on that codebase. Any similarity between this and my actual job may or may not be purely coincidental – I don’t really want to go into what Audatex‘s development plans are on a public blog!
For the test, I’m using two laptops – one with just VS2005SP1 and one running both VS2005SP1 and VS2008. All installations are of Visual Studio Professional. We’ll call the “just VS2005SP1” laptop “Dull” and the “VS2005SP1 and VS2008” laptop “Shiny”. All tests will be done with plain console projects, just to keep sanity intact. I realise there may be other issues with other project types. Both laptops have the fabulous ReSharper installed for VS2005, but I’m hoping that won’t make any difference. I never took a backup when converting a solution or project. I haven’t included .suo files, as they shouldn’t be relevant.
Test 1: Simple upgrade
Dull: Create new solution (Test); add console project (Project1).
Shiny: Copy solution; open with VS2008; compare solution and project files.
Test.sln: Differences on lines 2 and 3. The original was:
# Visual Studio 2005
After conversion, the format version became 10.00, and the 2005 became 2008.
Project1.csproj: After conversion, the first line has an additional
ToolsVersion="3.5" attribute in the
Project element. There is also an extra piece of XML in the
Test 2: Move project file back to Dull
Dull: Copy just the project file from the upgraded Test1 back onto Dull, and reopen solution
Results: Solution and project both opened with no issues.
Test 3: Move solution file back to Dull
Dull: Copy the solution file from the upgraded Test1 back onto Dull, and reopen solution
Results: Unsurprisingly, this failed with an error message: “The selected file is a solution file, but was created by a newer version of this application and cannot be opened.”
Test 4: Add a project in VS2005
Dull: Add a new project (Project2)
Shiny: Copy over project directory; in VS2008 select “Add existing project”
Results: Same differences in Project2.csproj as before in Project1.csproj
Test 5: Add a project in VS2008
Shiny: Add a new project (Project3)
Dull: Copy over project directory; in VS2005 select “Add existing project”
Note that the new project was targeting .NET 2.0; I haven’t tried targeting other frameworks, but I’d imagine there could well be issues there.
Results: Initially, an error message complains about failing to find
Microsoft.CSharp.targets. This is due to a difference in the project files, near the bottom. The VS2008 project has this:
A project created in VS2005 has this instead:
Note the difference between “Bin” and “Tools”. After editing the file manually, both VS2005 and VS2008 are able to open it, and neither one tries to change the file back again.
Test 6: Using C# 3 features
var (local variable type inference) in a code file
Dull: Attempt to compile under VS2005.
Results: It comes as no surprise that we have code which builds under VS2008 but not under VS2005. Not good.
Test 7: Preventing VS2008 from using C# 3 features
Shiny: Edit Project3.csproj to set the ToolsVersion attribute to 2.0 instead of 3.5, then rebuild
Results: Disappointingly, it still builds under VS2008. However, other users have reported this as doing the right thing. Currently I don’t know what’s going on here.
Test 8: Trying harder…
Shiny: Edit Project3.csproj to add a LangVersion element. Inside the PropertyGroup element, I added this and rebuilt, based on guesswork from the
Dull: After removing the C# 3 code, copy the project file to test if VS2005 still understands it.
Results: Aargh! VS2005 now complains that LangVersion can only be ISO-1 or Default. Stalemate.
- It’s possible to share project files but not solution files between VS2005 and VS2008.
- If you upgrade a solution file by mistake, it’s very easy to fix it by hand.
- If you decide to maintain different solution files, if there are big changes in one it may be easiest to just make them in one solution, then upgrade again.
- Creating a project in VS2005 and then importing it into VS2008 is seamless; the other way round has slight issues which are fixable by hand.
- I don’t know of a way of forcing VS2008 to only use C# 2 while at the same time maintaining VS2005 compatibility.