Visual Studio 2008 uses MSBuild 3.5 which supports multi-targeting: you can use it to compile applications for .NET 2.0, .NET 3.0 and .NET 3.5.
But what happens if you open an MSBuild 2.0 project (Visual Studio 2005 or SharpDevelop 2.x project) in Visual Studio 2008?Answer: The “Visual Studio Conversion Wizard” will pop up and “convert” the project to MSBuild 3.5. Though it does generate a fancy upgrade report that looks like source files have been converted, all it does for a normal Windows Application is the following:
Note that even though the C# 3.0 compiler is used, the project is still compiled for .NET 2.0. The new C# 3.0 languages features are available, but LINQ cannot be used because it requires referencing System.Core.dll, which comes with the .NET Framework 3.5.So the converter did only minor changes, but they prevent working with both VS 2005 and VS 2008 on the same project.
Currently, SharpDevelop does not use the multi-targeting model of VS 2008, but continues to use the model of SharpDevelop 2.x: The “Target Framework” setting in the project options allows you to choose the compiler to work with. If you choose C# 2.0 / .NET 2.0, SharpDevelop will not use ToolsVersion=”3.5” on the project, and will create a solution file version 9. Only if you choose the C# 3.0 compiler, it will make the project an MSBuild 3.5 project and mark the solution as version 10.
However, this introduces several problems:C# 2.0 does not support embedding manifest files in assemblies, but C# 3.5 embeds a default manifest file automatically. Simply changing the target framework changes the manifest behavior.
MSBuild 2.0 does not check whether the assemblies you referenced are available in the target framework you have chosen. SharpDevelop can fix this by doing the check on its own.
The target framework is an option that normally can be dependent on the chosen configuration/platform. However the ToolsVersion attribute in MSBuild cannot be dependent on configuration/platform. If one configuration uses C# 3.0, all configurations will; even if they are explicitly set to C# 2.0.
WPF Applications created in SharpDevelop 2.2 use a different way to support XAML and resource compilation than MSBuild 3.5 uses. Such applications can be edited in SharpDevelop 3.0 and will continue to work even though they are set to C# 2.0 / .NET 2.0 in the options. Setting these projects to C# 3.0 causes problems that can only be fixed by manually editing the .csproj file.
So what should we do?
1. “Keep it broken” has the advantage that it’s zero work for us2. Would be the easy to implement, but means that you cannot use SharpDevelop 3.0 if your co-worker still uses SharpDevelop 2.x or Visual Studio 20053. Would be more work than 2, but is the most flexible solution
So do you think the ability to edit VS 2005 projects is worth the effort of implementing 3 instead of 2?