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.
From discussion on Monodroid forum:
I also had this problem. It is a result of VS 11 changing the version number of the solution.
If you open the sln in notepad the first two lines will be (bad):
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 11
instead of (correct):
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010
You should be able to change it back to version 11.00.
We should probably tell the MonoDevelop guys...
On Sat, May 5, 2012 at 9:12 PM, Stuart Lodge <firstname.lastname@example.org> wrote:
Recently I've had some .sln files refuse to open in MonoDevelop - basically it just opens them for edit as binary files rather than as solutions.
I'm not sure if this is because I've installed too much VS11 stuff on my dev box, or if it's a change in MonoDevelop...
Anyone else seen this? Anyone any idea why this is happening to me - other than karma :)
When you do that, will VS2010 open the solution?
VS11 is supposed to have support for editing VS2010 solutions without upgrading them unless you opt in to some newer feature that requires the new format.
Yes - VS10 still opens these solutions - indeed I think it is even saving them as the new version (I think installing vs11 has changed some of vs10 - certainly this is true for things like the references frameworks and the portable library support)
Just nudging this one back into motion
Created attachment 1961 [details]
This is a very incomplete patch, but there's a lot of variables I don't know at the moment
I'll let someone else take over from here.
*** Bug 7453 has been marked as a duplicate of this bug. ***
Jeff, what will it take to fix this or who should take over?
It takes the momentum out of development. I open my solutions in Visual Studio and in MonoDevelop constantly, switching between the two environments maybe 10-20 times a day. I uninstalled Visual Studio 2012 and went back to VS 2010 until this is fixed. I hope you find a solution soon.
There are also minor differences in the .csproj files; VS 2012 is now using lowercase letters for things like '<Optimize>true</Optimize>' or project guids.
These files were created with Visual Studio 2012 Express:
Created attachment 2659 [details]
Difference between VS2k12 and MonoDevelop
I manually edited to .sln to 'Format Version 11.0', then loaded the solution in MonoDevelop.
The patch shows how MonoDevelop modifies the .csproj files when saving them.
The casing isn't that simple. Those values are read case insensitively. Project files in VS are created from textual templates, and the literal values are not modified unless the setting is changed in the IDE. So newly created projects can actually have a mixture of cases. MD does a full deserialize-serialize, so it's more consistent.
*** Bug 7776 has been marked as a duplicate of this bug. ***
Project created in VS2012 does not open in MD successfully. It just display .sln file in hex editor. We have open this file on both Windows and Mac. On both, hex editor file displayed. While project created by VS 2010 opens successfully in MD.
All Mac and windows.
MD 188.8.131.52 - dd8226e1e8746c66c55fff3292bcca499e5f7d25
MFA 4.2.8 -88acfed004937da9bc7c0247d4b62c7e1633c1dc
Anyone working on this? I want to reinstall VS 2012! :)
Michael: should I commit my patch? How incomplete is it? I really have no idea what needs to be done to add support for this new format beyond what my patch does.
Jeff, your patch (or a variant) appears to have been committed to master already. However, it looks incomplete, and possibly incorrect. For start, I can't find any evidence the ProductVersion is "11.0.0" - where does this come from? The name/id is inconsistent with the other formats, IMO should be MSBuild12/MSBuildFileFormatVS12, not MSBuild11/MSBuildFileFormatVS11. We need to change the various project types to declare support for this file format. We need to figure out what features trigger the upgrade to VS2012 format, and whether we should require building against a 4.5 runtime despite the unchanged "4.0" toolversion.
I'm not eve convinced it completely counts as a new format, I think we might just have to alter the VS2010 format to allow the new constants in the sln file, since VS2010 is supposed to be able to open solutions that have been edited by VS2012 - so in a sense they're still VS2010 solutions.
IMO we need to get Lluis to take a look, since solution formats are his area.
VS 11 == VS 2012
Right, but it's an issue of consistency. MD internally names the other formats MSBuild05, MSBuild08, MSBuild10 - not MSBuild8, MSBuild9, MSBuild10.
*** Bug 4665 has been marked as a duplicate of this bug. ***
VS12 can open VS10 solutions without converting them, and it keeps the VS10 format when saving.
VS10 can't open solutions created with VS12.
VS12 does not define the ProductVersion variable anymore.
The current VS12 file format class we have looks mostly correct to me. I committed some changes though:
* renamed the class and format id to MSBuild12
* allow reading sln files with format version 11 (vs12 betas used that number), although they are saved as 12
in which version will your fixes land?
My project was done in monodevelop so far. Now I want to add support for Windows8 in VS2012.
Once I open a .CS file, VS changes the SLN. This new SLN can not be read by my monoDevelop version, which completly freaks out :-(
Mono for Android: 4.2.8
ok, another comment from me...
when I ONLY change back the version information (12.00 -> 11.00), then in my case monoDevelop is happy again... :)
The fix will be included in the next MonoDevelop release.
*** Bug 8236 has been marked as a duplicate of this bug. ***
Please can someone clarify if this next release will also fix things like the capitalization reported above in Comment 9 - https://bugzilla.xamarin.com/show_bug.cgi?id=4919#c9
I'm hitting problems currently trying to use VSMonoTouch - especially with fields like <NoStdLib> where Visual Studio needs:
But MonoDevelop instead overwrites this with:
This is currently making code sharing between Windows and Touch quite tricky.
What do you mean, VS "needs" that capitalization? What breaks?
There's some difference between the way VS and MD include a reference to mscorlib, which has meant that <NoStdLib>true</NoStdLib> is needed in the MonoTouch .csproj files.
I don't understand fully the reasons for this - but I've been happily using <NoStdLib>true</NoStdLib> for the last 6 months.
However, when MD changed this line to <NoStdLib>True</NoStdLib> then the VS compilation broke - sadly True with a capital T seemed to be equivalent to <NoStdLib>false</NoStdLib>
For some background on this, see https://github.com/follesoe/VSMonoTouch/issues/12 and also see "A note on mscorlib.dll" in https://github.com/follesoe/VSMonoTouch/blob/master/Readme.md
Reopening following advice on http://forums.xamarin.com/discussion/344/bugzilla-etiquette#latest
The <NoStdLib>True</NoStdLib> problem is a serious one as VS2010/VS2012 seem to treat this as equivalent to <NoStdLib>false</NoStdLib>
I tested with VS2012 and it considers 'true' and 'True' to be the same. I created a console project and added <NoStdLib>True</NoStdLib> to the csproj, and when building VS complains about missing mscorlib, as it should, which means the flag is properly loaded. I tested with VS2010 and it does the same. So I don't think we are doing anything wrong.
Thanks Lluis - very useful.
Am retesting here. Maybe this is something to do with VSMonoTouch - will keep digging into what meant I had to do commits like this: https://github.com/slodge/MvvmCross/commit/2ed27b78c4a20f252eeb185e445072e511335fbb
Thanks again Lluis
First up - THANKS and **SORRY**
I definitely got it wrong about what was causing the problem...
I've been playing for a couple of hours on this, and I'm struggling to explain quite what I'm seeing at present.
- I can reproduce your results on the tip of my repo.
- I can also reproduce that if I revert to https://github.com/slodge/MvvmCross/commit/43cfb471b6b97f7249d42ff8ff5cc4105f3d2460 then System.Windows.Touch (and others) won't build in my repo
- And if then roll forwards one hop to https://github.com/slodge/MvvmCross/commit/2ed27b78c4a20f252eeb185e445072e511335fbb then System.Windows.Touch and all the others build.
- And the only changes in that commit are csproj level changes...
I think this must be solved in the Head of my repo because I've removed a lot of AdHoc, etc configurations from the libraries. But I'm not sure...
Please close this issue again - I'll keep looking at this when the problems occur and will feed back any solid evidence I can find.
Thanks and **sorry** again
Stuart (slightly confused but really very happy to be sharing projects between VS and MD again!)
ok, np, closing.