C#

VS2005 and VS2008 co-existence

18 Comments

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!

Test environment

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.

Results:

Test.sln: Differences on lines 2 and 3. The original was:

Microsoft Visual Studio Solution File, Format Version 9.00
# 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 PropertyGroup element:

<FileUpgradeFlags>
</FileUpgradeFlags>
<OldToolsVersion>2.0</OldToolsVersion>
< UpgradeBackupLocation>
</UpgradeBackupLocation>

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:

<Import Project=”$(MSBuildToolsPath)Microsoft.CSharp.targets” />

A project created in VS2005 has this instead:

<Import Project=”$(MSBuildBinPath)Microsoft.CSharp.targets” />

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

Shiny: Use 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 csc options:

<LangVersion>ISO-2</LangVersion>

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.

Conclusion

  • 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.

18 thoughts on “VS2005 and VS2008 co-existence”

  1. The reason why “var” is supported tough you’ve selected “2.0 Platform” is that neither “var” nor Lambda Expressions use new Platform features, only the Compiler and IntelliSense got updated to be a bit “smarter”. Your assembly will thus be runnable under the 2.0 Platform.

    That behaviour of VS.NET is correct. The only way to force “C#2.0” language features is to simply not use them. If you are using a version control system you could do a RegExp check on checked-in files and warn if developers check in files with svars or .*=>.*.

    With a VCS you could also automate the process of keeping the V10 and V9 SLN files in sync, and to check for potential problems in the VCPROJ files ( $(MSBuildToolsPath) ).

    By the way: It should be possible to force VS.2005 to compile those 2008 solutions with the new C#3.0 compiler, as long as it is installed. It should work the same way as back when it was needed to force 2003 to compile with the VC6 compiler.

    Like

    Reply

  2. Stefan,

    I have no problem with “var” being supported by default when targeting .NET 2.0, but that’s not what my change attempted to achieve. It wasn’t changing the target *platform*, it was trying to change the *tools* used for building the solution. As I understand it, setting ToolsVersion to 2.0 should mean that the 2.0 compiler is used, forcing only 2.0 features to be used. That didn’t work on my box, despite the experiences of others.

    Saying ‘The only way to force “C#2.0” language features is to simply not use them’ is both unsatisfactory and incorrect.

    Unsatisfactory: relying on people just getting it right when it should be easy to automate is always unsatisfactory. All we need is to use the C# 2 compiler when building.

    Incorrect: As I’ve shown, using the LangVersion element forces the compiler to acknowledge C# 3 features – the pity is that it’s not supported under VS2005.

    The “mixed IDE” development is likely to be common for a while, and it’s a shame that it doesn’t work *quite* as well as it should do. Allowing VS2005 developers to build C# 3 code is certainly a step in the right direction (although I haven’t looked into how easy that would be to do) but it means that all devs need to learn C# 3 in order to understand their colleagues’ code, which isn’t ideal.

    Jon

    Like

    Reply

  3. I might be wrong but it seems to be that some of the features of the 3.5 Framework being purely sintatic sugar, we can still compile targeting the 2.0 when using them. In my experience I created a simple class with automatic properties and it also compiles. I guess it’s creating a private field on the fly anyway, so it’s compilable… same thing with vars, since the compiler will just replace the

    var x = 3;

    for

    int x = 3;

    Like

    Reply

  4. Firstly, the features of the “.NET 3.5 framework” are *not* syntactic sugar – and can’t be, as syntactic sugar is a *language* feature. It’s worth differentiating between the framework and C# as a language.

    That said, almost all the features of C# 3 are available targeting .NET 2.0, with the following caveats:

    1) Without the expression tree support in the framework, the compiler can’t output expression tree creation code.

    2) Using query expressions requires support of whatever you’re trying to call them on, or extension methods – but basically you need whichever Select, Where etc methods you’re going to call. I believe there’s an open source LINQ to Objects provider being written to target .NET 2.0, but I haven’t looked at it.

    3) Extension methods require an attribute which you can declare yourself, but it’s a bit of a hack.

    The point of this original post, however, was to *prevent* the unintentional use of C# 3 features when it would screw up other developers having to compile the same code with a C# 2 compiler.

    Stefan, one point I meant to mention before: yes, *some* features can be detected with a regular expression, but I think you’ll find it rather harder to work out whether the type inference rules of C# 2 are adequate or whether a particular expression relies on the new rules in C# 3, without basically building a compiler yourself.

    Jon

    Like

    Reply

  6. When I convert a project it says everything goes according to plan but when I Open the new project file in VS2005 I’m told “The selected file is a solution file, but was created by a newer version of this application and cannot be opened.”

    When I Open it with VS2008 I receive the VS Conversion Wizard which makes me think it was actually converted back to VS2005.

    Like

    Reply

  7. Very nice. I used this information to create a knowledgebase wiki for my tech team, should they encounter a VS2008 solution and they haven’t installed VS2008 yet. Thanks for the information, it is most helpful.

    Like

    Reply

  9. For info – note that web-application-projects may have some issues, due to the extra import:

    The 8.0 is important; VS2008 will detect this (even if other project changes applied) and the upgrade wizard will whack to 9.0; but this will then fail on VS2005-only machines.

    Copying the .targets file and letting 2005 open it with the 9.0 raises a security prompt (once-per-project).

    Like

    Reply

  10. Installed VS2008 thinking that other team members running VS2005 would not run into many problems when opening my solutions created with from VS2008. I’m afraid yes, definitively there are big problems…until I discovered ProjectConverter utility from graye.

    Thanks graye for developing such a useful tool!

    Like

    Reply

  12. For a while I used VS2005 at home and VS2008 at work. Since I often swapped projects between the two so I could work at home, my method was to simply create new controls in the other and copy the source (which never changed). I’ve since decided to use VS2005 at work to simplify the situation, but I had to port my 2008 projects back to 2005. I figured it was simply a matter of changing a few details, but I didn’t know exactly which ones. Your experiment has been a great help. Thanks!

    Like

    Reply

  15. Many thanks for this conversion utility – I have untied the noose around my neck and i am not jumping of this table now :¬)

    Like

    Reply

Leave a comment