Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Now there is a check in MSBuildProjectHandler.cs (line 897) which throws away TargetFrameworkVersion if it's equals to default one for current configuration.
But in fact it breaks compatibility with VS2008 in our solution. I have both 3.5 and 4.0 frameworks installed and all projects targeted on 3.5. MonoDevelop removes TargetFrameworkVersion from project files and now VS2008 thinks that projects should be built with 2.0 framework and thus can't find some linq assemblies.
The question is, is this problem because the default we're using for VS2008 projects is wrong, or because VS2008 requires a TargetFrameworkVersion element?
I believe it's the first point. Just checked with SharpDevelop 3.2 and 4.1 - they both think that the target framework should be 2.0 without TargetFrameworkVersion element.
So I think it's better to change default version for VS2008 from 3.5 to 2.0 for better compatibility.
Michael: How hard would this be to fix?
This issue is driving me crazy since I use both MonoDevelop and VS2008. Moreover, I work with collegues addicted to VS2008, and it's becoming a big issue.
Can I help to fix it?
What about simply keep the TargetFrameworkVersion tag even if it has the default value? Bits are cheap these days!
Looks at https://github.com/mono/monodevelop/pull/138 for a possible fix.
That fix isn't correct, it will break new projects and projects where the target framework is changed.
The actual problem is that DotNetProject.GetDefaultTargetFrameworkForFormat is used both for setting the target framework for newly created projects and for specifying the default target framework of the msbuild targets. If you look in DotNetAssemblyProject.GetDefaultTargetFrameworkForFormat, it sets the default framework for the MSBuild08 format as ".NETFramework,v3.5". This is indeed what we want for *new* MSBuild08 projects. However, the default target framework of the matching Microsoft.Common.targets is actually 2.0.
Fixed in git.