Bugzilla – Bug 4919
VS11 breaks sln files
Last modified: 2012-11-22 04:32:10 EST
From discussion on Monodroid forum:
I also had this problem. It is a result of VS 11 changing the version number of
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 <email@example.com> 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
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
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
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 22.214.171.124 - 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
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
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 -
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
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
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:
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
then System.Windows.Touch (and others) won't build in my repo
- And if then roll forwards one hop to
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.