Why won't my generated .sln file open in Visual Studio 2010? - c++

Question

I'm dealing with a fairly large C++ code base. The code base is normally intended to be compiled under Linux, using custom build scripts and makefiles. I'm porting the code into Visual Studio, which as anyone who's used Visual Studio would agree, is a pain to do manually.
My own looking has been kind of fruitless, so I started writing my own utility in Qt to analyze the codebase and generate a solution file and accompanying .vcxproj files. I've been using the QUuid class to generate GUIDs for each of the projects, and I'm using QTextStream to write the .sln file.
Now, here's the problem: When I open the generated .sln file, I see the following errors.
I'm currently trying to generate a solution that I've already manually created within the Visual Studio IDE. I've compared my generated .sln file against the the one Visual Studio created, and apart from the projects appearing in a different order and the GUIDs not matching (obviously), I can't spot a difference. I'm including a simplifed example of my problem here.
Visual Studio generated this:
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "mylib", "mylib\mylib.vcxproj", "{35BAFEEE-35FA-4313-AF67-AF8AB7458451}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Release|Win32 = Release|Win32
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{35BAFEEE-35FA-4313-AF67-AF8AB7458451}.Debug|Win32.ActiveCfg = Debug|Win32
{35BAFEEE-35FA-4313-AF67-AF8AB7458451}.Debug|Win32.Build.0 = Debug|Win32
{35BAFEEE-35FA-4313-AF67-AF8AB7458451}.Release|Win32.ActiveCfg = Release|Win32
{35BAFEEE-35FA-4313-AF67-AF8AB7458451}.Release|Win32.Build.0 = Release|Win32
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal
And I generated this:
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "mylib", "mylib\mylib.vcxproj", "{A09FDB84-49CD-4C14-9D7D-D813D2D905EF}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Release|Win32 = Release|Win32
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{A09FDB84-49CD-4C14-9D7D-D813D2D905EF}.Debug|Win32.ActiveCfg = Debug|Win32
{A09FDB84-49CD-4C14-9D7D-D813D2D905EF}.Debug|Win32.Build.0 = Debug|Win32
{A09FDB84-49CD-4C14-9D7D-D813D2D905EF}.Release|Win32.ActiveCfg = Release|Win32
{A09FDB84-49CD-4C14-9D7D-D813D2D905EF}.Release|Win32.Build.0 = Release|Win32
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal
Here are my questions:
What do these specifc error messages mean?
Is there any way I can get more specific information on what's wrong with the .sln file?
Is there something wrong with the GUIDs I'm generating? Should I be using the Visual Studio tool to create GUIDs?
Is there some metadata or other invisible special sauce in the file that I'm missing?
I'm pretty sure the issue isn't with text encoding--I used notepad to create a UTF-8 version of the .sln and tried opening that instead.
In light of everything, it seems like my GUIDs are causing the issue--though I'm not sure how or why.
Update
The only major difference I noticed between these files was the file size. The two files differ by exactly 3 bytes, but I couldn't see anything in the file using my text editor. However, an article by Joel Spolsky got me thinking. There ain't no such thing as plain text--everything's just a representation of 1's and 0's, after all.
I opened up the two files in a hex editor, and presto, I found the 3 bytes at the start of the Microsoft-generated file! (0xEF, 0xBB, 0xBF). These three bytes also appear in a Visual Studio 2008 solution I had lying around on a different machine. I could probably write my code to slip these bytes into the file before I start writing the solution, but that still begs the question:
What the heck are these bytes for, and why is Microsoft using them?

Answer 1

What you are contemplating is a UTF-8 byte order mark.
It is used to indicate that the file is UTF-8 encoded, and it is supposed to be rendered as a blank, zero width space. If you have the choice, please don't use it -- it makes the file more difficult to read with standard text editors.
Opening the file with notepad and saving it as UTF-8 encoded text will add those three bytes for you. But again, don't use the BOM on files which are meant to be portably read.

Answer 2

Debug Visual Studio with Visual Studio:
Before opening your generated solution with Visual Studio, open another instance of Visual Studio, go to Debug->Exceptions and check all the check boxes, then go to Debug->Attach to Process... and attach to devenv.exe. Now open the solution in the other VS, and you'll get a break and a call stack which might give you more information.

Answer 3

To add to the answer I accepted, in the case of Qt, I made use of the following method in the QTextStream object I was using to write the solution file:
void QTextStream::setGenerateByteOrderMark ( bool generate )
Syntax is like so:
QFile fileHandle("mylib.sln");
QTextStream fileStream(&fileHandle);
// ...file open and error handling goes here...
fileStream.setGenerateByteOrderMark(true);
fileStream << "\nMicrosoft Visual Studio Solution File, Format Version 11.00\n";
//etc, etc
This will make sure that your file has the Byte Order Mark, which in this specific case, Visual Studio needs in order to open the file.