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
Summary: VS11 breaks sln files
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Project Model (show other bugs)
Version: unspecified
Hardware: PC Windows
: High critical
Target Milestone: ---
Assignee: Lluis Sanchez
URL:
: 4665 7453 7776 8236 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-05-07 06:19 UTC by Stuart Lodge
Modified: 2012-11-22 04:32 UTC (History)
9 users (show)

See Also:
Tags:


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

Description Stuart Lodge 2012-05-07 06:19:58 UTC
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 mhutch 2012-05-07 10:57:33 UTC
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 UTC
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 UTC
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 UTC
Just nudging this one back into motion
Comment 5 Jeffrey Stedfast 2012-05-25 16:24:18 UTC
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 UTC
*** Bug 7453 has been marked as a duplicate of this bug. ***
Comment 7 PJ 2012-09-26 12:51:25 UTC
Jeff, what will it take to fix this or who should take over?
Comment 8 Ricky Helgesson 2012-09-27 02:00:35 UTC
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 UTC
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 UTC
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 mhutch 2012-10-01 14:44:45 UTC
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 UTC
*** Bug 7776 has been marked as a duplicate of this bug. ***
Comment 13 Saurabh 2012-10-11 03:29:42 UTC
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 UTC
Anyone working on this? I want to reinstall VS 2012! :)
Comment 15 Jeffrey Stedfast 2012-10-11 13:46:14 UTC
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 mhutch 2012-10-11 23:24:44 UTC
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 UTC
VS 11 == VS 2012
Comment 18 mhutch 2012-10-12 13:25:02 UTC
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 UTC
*** Bug 4665 has been marked as a duplicate of this bug. ***
Comment 20 Lluis Sanchez 2012-10-24 10:40:26 UTC
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 UTC
@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 UTC
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 UTC
The fix will be included in the next MonoDevelop release.
Comment 24 Lluis Sanchez 2012-11-06 02:51:06 UTC
*** Bug 8236 has been marked as a duplicate of this bug. ***
Comment 25 Stuart Lodge 2012-11-10 16:12:48 UTC
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 mhutch 2012-11-11 17:43:12 UTC
What do you mean, VS "needs" that capitalization? What breaks?
Comment 27 Stuart Lodge 2012-11-12 02:24:05 UTC
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 UTC
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 UTC
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 UTC
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 UTC
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 UTC
ok, np, closing.

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