Visual Studio Version Selector fails on LF formatted sln files by Oliver Mellet

This seems to have been closed 5 years ago inadvertently. As has been pointed out, this works in version 2010. It was a bug in the //BUILD release of Visual Studio, but has been fixed in the recently announced Beta. Sorry for the confusion. The //BUILD issue is tracked here: http://connect.microsoft.com/VisualStudio/feedback/details/689201/vs-2010-crashes-after-installing-vs-11-developer-preview


Matt Kaufman
Senior Program Manager, Visual Studio Platform
blogs.msdn.com/b/visualstudio

Please fix this

Seriously? A solution file with LF endings IS VALID, and can be opened in VS 2010.

It is the *launcher* which fails to recognize a valid solution file. Thus, this is indeed a bug.

The behaviour is that the version selecter silently dies with no error message or warning, leaving the user totally confused. What sort of "design" is this? When did it become acceptable to pass off valid user issues as "by design"? It's not like this software is free.

@Jeff Abraham,
"The solution files aren't intended to be edited by hand"
the problem is that it is actually never modified by hand. It is the version control system that auto converts the line endings when committing.
I have been using git, and there is an option the set the auto crlf to true or false.

here is a link diescribing it http://help.github.com/dealing-with-lineendings/

i think the best solution would be for visual studio to warn and change the line ending when opening the project, or either be able to accept both windows and linux line endings format.

The "by-design" answer is so unacceptable...

Hi

I too have just spent time trying to find why it didn't work. In my case the file had been saved in MKS Source (source-control system) by another developer - eventually I spotted that I could open the previous version OK but not this one. The differences all looked OK, as the change of end-of-line character was not visible. Eventually a web search found this discussion, and all was revealed.

Incidentally, once you have open it using File/Open in Visual Studio, save the file again (even with no changes) and it will correct the problem.

Jeff,

I'm sorry but this "by design" attitude that I see over and over and over in these bug reports is a pathetic. Is the CRLF formatting of the file really that important to its functioning? Yes, if the sln file's content is out of whack, then I can see not opening the file, but CRLF vs LF?

How about an error message or perhaps the option to actually fix the file? I've spent several hours trying to track down why this solution won't open, thinking there is something wrong with my computer, reinstalling VS.Net 2008 and 2005 thinking there was some conflict between how they were registered with the OS, combing thru the files looking for syntax problems, never once thinking that the line end formatting was the problem.

I can understand that you are busy with many other bugs and this may seem a trivial concern, but the attitude at microsoft too often is disrespectful to your customers who just want their tools to work so they can do their jobs.

Regards
Dan

Hoi,

Also, same bug appears when editing the sln by hand, and when the editor software doesn't prepend the UTF8 BOM (EF BB BF) to the beginning of the file (even if the file has utf encoding)...

VS2008, .NET 3.5: if some.sln doesnt have the BOM at the start of the file, then the windows explorer will list the file as "unrecognised version", and refuses to launch VS with the solution when double-clicking on it... However, I can open the solution using File/Open in Visual Studio ...

Bye,
Zs

I'm not editing the files by hand, it's a side-effect of our source control system. We're using Perforce; if you have a unix workspace, by default the files will be copied to the client using LF-terminated lines. If you then try to open a solution file from a network share that has files copied in this manner, it fails. It's a rare case, admittedly, but it can happen.

Hi Oliver,

Failing on LF formatted solution files is, at the moment, by design. The solution files aren't intended to be edited by hand, and they should be considered opaque, with CR/LF part of the format. Is there some scenario that you are working with that is triggering this behaviour, or is this just something you happened to notice after editing a solution file? Thanks,

Jeff Abraham
Visual Studio Tool Platform