Laputa

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:

In the .sln file, the solution version is set from 9.00 to 10.00, and the “# Visual Studio 2005” line is replaced with “# Visual Studio 2008”. This causes the Visual Studio loader to run VS 2008 instead of VS 2005 when the .sln is double-clicked.
In the .csproj file, the attribute ToolsVersion=”3.5” is inserted. This causes MSBuild to use the C# 3.0 compiler.
The property “<OldToolsVersion>2.0</OldToolsVersion>” is inserted, and two properties FileUpgradeFlags and UpgradeBackupLocation are introduced, but not set to a value. This has no effect on compilation.
In the .csproj file, the Resources.Designer.cs file got marked as “<DesignTime>True</DesignTime>”, which has no effect on compilation.
All files generated by a custom tool (Resources.Designer.cs and Settings.Designer.cs) get regenerated.
All other source files remain unchanged.

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?

Keep it as it is: works for usual projects, has the problems mentioned above
Do it like VS 2008, drop support for the C# 2.0 compiler and force conversion of the project
Disable the “Target framework” combo box until the user runs a conversion tool for that project (which could be a button next to the target framework combo box)

1. “Keep it broken” has the advantage that it’s zero work for us
2. 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 2005
3. 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?

Categories: Daniel

Sunday, September 30, 2007 5:26:53 PM (W. Europe Standard Time, UTC+01:00)

Comments [9]

Sunday, September 30, 2007 7:10:27 PM (W. Europe Standard Time, UTC+01:00)

I suppose it's better to maintain only one branch of SD development, so I like the idea of editing VS 2005 projects with SD 3 without conversion and recommend that version to .net 3.x/2.0 users.
So if I have understand the post, that is option 1 'keep it as it is'.

Anyway I don't imagine why .csproj should be edited manually if you change a WPF app to C# 3.0, the .csproj is not updated to MSBuild 3.5 format ?

If the problem is to maintain compatibility between SD 3.0 and 2.x, I see no problem in breaking that

Dan

Sunday, September 30, 2007 7:58:25 PM (W. Europe Standard Time, UTC+01:00)

C# 3.0 requires the MSBuild 3.5 format.
C# 3.0 can compile for .NET 2.0, 3.0 and 3.5.

So it is possible to support only C# 3.0 / MSBuild 3.5 and one can still develop for .NET 2.0 (this is option 2).
But other developers using SharpDevelop 2.x or Visual Studio 2005 won't be able to open the project after the conversion.

Both option 1 and 3 allow working on VS 2005 projects without converting them. In option 1 SharpDevelop will switch the project between 2.0 and 3.5 whenever you change the "Target framework" option, which has the problems mentioned in the post.
In option 3, the conversion from MSBuild 2.0 to 3.5 to an extra step separated from the combo box. This would make it more clear what's happening, and would solve the problem that the combo box allows choosing different target frameworks for different configurations but a project cannot be MSBuild 2.0 and 3.5 depending on the configuration/platform.
Option 3 also allows fixing the WPF projects from SharpDevelop 2.x automatically when the "convert" button is clicked.

Basically option 1 isn't really an option for me because it works incorrectly: you can set projects to C# 2.0 and they will still use the C# 3.0 compiler if they are set to C# 3.0 in ANY configuration.

So the question is: do you need to edit projects with SharpDevelop 3.0 so that they still can be opened in 2.x/VS 2005?
This is not an issue if you are developing alone, but what if you work on an open-source project? Do you think its reasonable to say "now that I use SharpDevelop 3.0, you all have to upgrade, too; or we have to use different project files which will break the build every time someone adds or renames a file" - and there are reasons for not upgrading: VS2008 - it costs money; SharpDevelop - plugins are not compatible, (at least now and in the beta phase) SD 3.0 is not as stable as 2.2.
Maybe it's not as important for most users as I thought and we can live with option 2. After all, that's what Visual Studio does...

Daniel Grunwald

Monday, October 01, 2007 8:33:12 AM (W. Europe Standard Time, UTC+01:00)

The issue is - how likely is it that once a project moves to C# 3.0 that someone still would want to open it up in an old IDE? Most likely the choice to move to C# 3.0 / .NET FW 3.5 is an explicit one, meaning that no developer on the project can decide on his own to stay behind (in companies no way, and even open source projects will make a clean cut).

So my take is that SD 3 Montferrer moves to the new MSBuild 3.5 format, that is, option #2.

Chris

Monday, October 01, 2007 10:01:41 AM (W. Europe Standard Time, UTC+01:00)

Mmm... so the plugin model changes in 3.0, and surely new cool plugins are going to born and SD 2.x developers will want them too.

Option 3 then, in my opinion adoption of .net 3.5 is going to be very slow ( LINQ is nothing revolutionary ) so it is very important to edit VS 2005 projects without conversion.

By the way, installation of current SharDevelop 3 bits requires the presence of .net 3.5, that can't be changed ? ( if you are not using some 3.5 facilities, probably the new CLR add-in model... )

Dan

Monday, October 01, 2007 12:10:23 PM (W. Europe Standard Time, UTC+01:00)

.NET FW 3.5 is a hard requirement for SharpDevelop 3

Chris

Monday, October 01, 2007 4:22:17 PM (W. Europe Standard Time, UTC+01:00)

MSBuild 2.0 uses C# 2.0 to compile for .NET 2.0 or .NET 3.0
MSBuild 3.5 uses C# 3.0 to compile for .NET 2.0, .NET 3.0 or .NET 3.5

With "MSBuild 2.0", I'm not referring to msbuild.exe, version 2.0; but to the set of MSBuild .target files coming with .NET 2.0.
With "MSBuild 3.5", I'm referring to the .target files coming with .NET 3.5.
SharpDevelop 3.0 will always use the .NET 3.5 MSBuild library (which is why .NET 3.5 is a requirement), but that version of MSBuild supports choosing the set of target files to use (this is what the project's "ToolsVersion" attribute is for).

When 'converting' a project, it is converted from MSBuild 2.0 / C# 2.0 / .NET 2.0 to MSBuild 3.5 / C# 3.0 / .NET 2.0.
The issue is not about forcing users into .NET 3.0 or .NET 3.5. The problem is not the target framework, but the compiler version/project file version. (Yes, the title of my blog post is bad.)

The problem with the current implementation is that the user interface must not combine compiler version and target framework into the "Target framework" combo box as it currently does: different target frameworks depending on the active configuration are supported, different compiler versions depending on the configuration are impossible. The way the compiler version is treated now leads to the problems outlined in the blog post.

What I'm asking is: should SharpDevelop 3.0 continue to support MSBuild 2.0 / C# 2.0?

Consequences if we drop support for MSBuild 2.0 projects:
- SharpDevelop 2.x / VS 2005 projects must be imported when they are opened
- after the import, the project cannot be opened in SharpDevelop 2.x / VS 2005 anymore.

Consequences if we keep support for both MSBuild 2.0 and MSBuild 3.5:
- the user must be made aware that choosing the compiler version results in a conversion of the project file
- features not supported in MSBuild 2.0/C# 2.0 (e.g. embedding manifests) must be disabled when the project is an MSBuild 2.0 project

If we keep support for MSBuild 2.0: how much support do we keep? One should be able to edit SharpDevelop 2.x projects without converting them, but what about creating new projects [in an existing solution]? What do we do with Compact Framework and Mono projects? What with .NET 1.x projects?

Daniel Grunwald

Monday, October 01, 2007 7:04:23 PM (W. Europe Standard Time, UTC+01:00)

I think it’s ok that the SD 3.x branch drops support for the .NET 2.0 compiler, solution 2, because I really want SD 3.x to be compatible with VS 2008. The SD 2.x branch should keep its solution format compatible with VS 2005 for teams that needs to support that version.

Marcus Holmgren

Monday, October 01, 2007 7:11:46 PM (W. Europe Standard Time, UTC+01:00)

SD 3.0 will be compatible with VS 2008 for C# 3.0 solutions. But we could additionally be VS 2005-compatible (with a button in the project options to switch between the file versions).

Note that there won't be any bug fix releases for SD 2.x anymore - currently I'm the only developer working on the main part of SharpDevelop and I don't have enough time maintain multiple branches.

But it seems that all except me think it's OK to drop MSBuild 2.0 support; so I think I'll drop it and spend the time that I will save by not implementing option 3 on other features.

Daniel Grunwald

Thursday, November 29, 2007 9:57:07 PM (W. Europe Standard Time, UTC+01:00)

BTW: after some more thought, I decided that opening existing projects without conversion is important enough; SharpDevelop 3.0 now implements option 3.
New projects are always created as MSBuild 3.5 projects, and there's no way to convert them back (unless you do it manually by reversing the steps mentioned in the post). So adding a new project to a solution will cause that solution be saved as VS08 solution.

Daniel Grunwald

Comments are closed.