This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 4919 - VS11 breaks sln files
: VS11 breaks sln files
Status: RESOLVED FIXED
Product: Xamarin Studio
Classification: Desktop
Component: Project Model
: unspecified
: PC Windows
: High critical
: ---
Assigned To: Lluis Sanchez
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-05-07 06:19 EDT by Stuart Lodge
Modified: 2012-11-22 04:32 EST (History)
9 users (show)

See Also:
Tags:
Test Case URL:
External Submit: ---


Attachments
vs11.patch (2.21 KB, patch)
2012-05-25 16:24 EDT, Jeffrey Stedfast
Details | Diff
Difference between VS2k12 and MonoDevelop (10.54 KB, application/octet-stream)
2012-10-01 04:25 EDT, Martin Baulig
Details

Description Stuart Lodge 2012-05-07 06:19:58 EDT
From discussion on Monodroid forum:

Hi Stuart,

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...

Matthew



On Sat, May 5, 2012 at 9:12 PM, Stuart Lodge <me@slodge.com> wrote:
Hi All

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 :)

Stuart
Comment 1 Michael Hutchinson 2012-05-07 10:57:33 EDT
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.
Comment 2 Stuart Lodge 2012-05-07 12:50:27 EDT
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)
Comment 3 Stuart Lodge 2012-05-07 12:50:27 EDT
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)
Comment 4 Stuart Lodge 2012-05-25 11:35:10 EDT
Just nudging this one back into motion
Comment 5 Jeffrey Stedfast 2012-05-25 16:24:18 EDT
Created attachment 1961 [details]
vs11.patch

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.
Comment 6 PJ 2012-09-26 12:50:05 EDT
*** Bug 7453 has been marked as a duplicate of this bug. ***
Comment 7 PJ 2012-09-26 12:51:25 EDT
Jeff, what will it take to fix this or who should take over?
Comment 8 Ricky Helgesson 2012-09-27 02:00:35 EDT
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.
Comment 9 Martin Baulig 2012-10-01 04:21:22 EDT
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:
https://github.com/baulig/Provcon-Faust/tree/master/TestWCF
Comment 10 Martin Baulig 2012-10-01 04:25:56 EDT
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.
Comment 11 Michael Hutchinson 2012-10-01 14:44:45 EDT
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.
Comment 12 Jackson Harper 2012-10-10 13:47:43 EDT
*** Bug 7776 has been marked as a duplicate of this bug. ***
Comment 13 Saurabh 2012-10-11 03:29:42 EDT
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.

Environment details:
All Mac and windows.
MD 3.0.4.8 - dd8226e1e8746c66c55fff3292bcca499e5f7d25
MFA 4.2.8 -88acfed004937da9bc7c0247d4b62c7e1633c1dc
MonoFramework-MDK-2.10.9_11.macos10.xamarin.x86
VS 2012
Comment 14 Ricky Helgesson 2012-10-11 03:37:50 EDT
Anyone working on this? I want to reinstall VS 2012! :)
Comment 15 Jeffrey Stedfast 2012-10-11 13:46:14 EDT
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.
Comment 16 Michael Hutchinson 2012-10-11 23:24:44 EDT
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.
Comment 17 Ricky Helgesson 2012-10-12 02:37:11 EDT
VS 11 == VS 2012
Comment 18 Michael Hutchinson 2012-10-12 13:25:02 EDT
Right, but it's an issue of consistency. MD internally names the other formats
MSBuild05, MSBuild08, MSBuild10 - not MSBuild8, MSBuild9, MSBuild10.
Comment 19 Andres G. Aragoneses 2012-10-21 12:12:16 EDT
*** Bug 4665 has been marked as a duplicate of this bug. ***
Comment 20 Lluis Sanchez 2012-10-24 10:40:26 EDT
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
Comment 21 Jens 2012-11-04 21:53:14 EST
@lluis:
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 :-(

MonoDevelop 3.0.5
Mono for Android: 4.2.8
Comment 22 Jens 2012-11-04 23:00:56 EST
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... :)
Comment 23 Lluis Sanchez 2012-11-05 03:55:31 EST
The fix will be included in the next MonoDevelop release.
Comment 24 Lluis Sanchez 2012-11-06 02:51:06 EST
*** Bug 8236 has been marked as a duplicate of this bug. ***
Comment 25 Stuart Lodge 2012-11-10 16:12:48 EST
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:

  <NoStdLib>true</NoStdLib>

But MonoDevelop instead overwrites this with:

  <NoStdLib>True</NoStdLib>

This is currently making code sharing between Windows and Touch quite tricky.
Comment 26 Michael Hutchinson 2012-11-11 17:43:12 EST
What do you mean, VS "needs" that capitalization? What breaks?
Comment 27 Stuart Lodge 2012-11-12 02:24:05 EST
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
Comment 28 Stuart Lodge 2012-11-13 06:53:35 EST
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>
Comment 29 Lluis Sanchez 2012-11-21 13:24:53 EST
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.
Comment 30 Stuart Lodge 2012-11-21 16:37:27 EST
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
Comment 31 Stuart Lodge 2012-11-21 17:28:53 EST
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!)
Comment 32 Lluis Sanchez 2012-11-22 04:32:10 EST
ok, np, closing.

Note You need to log in before you can comment on or make changes to this bug.