This one has caused me some problems recently. I have a Visual Studio solution I downloaded, yet double clicking on the solution file in Windows Explorer does not open the solution.
I know it's a Visual Studio 2010 solution, because the file starts with:
Microsoft Visual Studio Solution File, Format Version 11.00 # Visual Studio 2010
If I open Visual Studio 2010 and open the solution from within the editor, it works fine. This seemed to indicate that it was the way in which the Microsoft Visual Studio Version Selector was messed up somehow.
I did some research online (I can't claim any independent breakthrough here myself) and thought I would collate the various reasons I found why the version selector might not be able to open a solution.
If Visual Studio 2010 is set to run as administrator, and Visual Studio Version Selector is not, then the version selector does not have the necessary privileges to launch Visual Studio, and it silently fails. Thanks to Jonas Stawski for this one.
In Beta 1, the preamble to the solution file was as follows:
Microsoft Visual Studio Solution File, Format Version 11.00 # Visual Studio 10
Just change the 10 for 2010 on line 2, and away you go. Thanks to Jon Skeet for this tip.
Some Source Control providers can automatically change line endings. If the line endings are set to Unix (LF) instead of Windows (CRLF), then the Version Selector gets confused and can't determine which version of Visual Studio to launch, and instead silently fails. Thanks to Oliver Mellet for this.
Solution Files must be encoded using UTF-8 and include the BOM at the start (which is EF BB BF). If these criteria aren't met, then the Version Selector can't determine which version of Visual Studio to launch. Notepad++ can fix this up (Encoding –> Convert to UTF-8). Thanks to anoftc for this tip.
It seems that the Visual Studio Version Selector is very naive when trying to read solution files. I couldn't quite believe that the line endings would matter, or the encoding, so I had a play around in Notepad++ to verify the above.
Microsoft recommends that solution files shouldn't be modified by hand, but I've had to do this on a number of occasions, particularly when trying to mess with source control bindings. Also, source control providers can make changes to files as they're checked in, so it seems unrealistic to me to have the limitation that solution files shouldn't be modified except by Visual Studio itself.
I hope the above reasons help someone out.