Solution File(.sln)

The solution file organizes all the projects in folders and optionally stores dependencies too. At the solution level, dependencies are more than just build dependencies. As you recall build dependencies are always executables or dynamic libraries that link against static libraries. But, there are other dependencies too. If you have an executable E that loads a dynamic library D you want to make sure that D is up to date when you test E, so for testing purposes you may want to add a dependency of E on D. This will cause D to be built before E is built (although the order doesn't matter) and you can be confident that you test the same version of E and D.

Back to the solution file, the format is proprietary but fairly simple. The main concept is the "Project", which can be either a Visual Studio project (captured in a .vcproj file in the case of ibs) or a virtual folder that contains a number of other projects. The folders are not file system folders, but are used in the Visual Studio IDE for organizational purposes. Folders can be nested and can contain other folders or actual projects. Each project (either a real project or a folder) has a GUID (globally unique identifier) associated with it. The .sln file is using the GUIDs to refer to projects. The reason is that the solution may contain projects with identical names and it is easier to distinguish between them by GUID then by absolute path to a project file, which may not work in case of relative paths.

The file format consists of project elements that includes the project dependencies if any followed by a few global sections that determine the folder nesting and what projects participate in the build.

The dependencies are specified as GUIDs. The path to the project file is specified if there is a project file. Here is the project section of the "testHello" test project:

Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "testHello", "test\testHello\testHello.vcproj", "{5F46CA1C-88BC-4E19-BB65-8686B453441D}"
	ProjectSection(ProjectDependencies) = postProject
		{D0736B61-D7AE-4B50-99FF-1AC604AF83D1} = {D0736B61-D7AE-4B50-99FF-1AC604AF83D1}
		{7A0F57A3-00B8-4879-BBE1-318E3FC0A526} = {7A0F57A3-00B8-4879-BBE1-318E3FC0A526}
	EndProjectSection
EndProject

In case of a folder the folder name is used instead of a path to the project file and there are no dependencies:

Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "test", "test", "{64EECA44-A21D-4FB3-8C2C-3D3B81EE2F3C}"
EndProject

The Global part of the file contains multiple global sections. The configurations section contains the available configurations (by default Debug and Release) and which ones should be built. It is divided into two global sections marked preSolution and postSolution.

	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug|Win32 = Debug|Win32
		Release|Win32 = Release|Win32
	EndGlobalSection
	GlobalSection(ProjectConfigurationPlatforms) = postSolution
		{5F46CA1C-88BC-4E19-BB65-8686B453441D}.Debug|Win32.ActiveCfg = Debug|Win32
		{5F46CA1C-88BC-4E19-BB65-8686B453441D}.Debug|Win32.Build.0 = Debug|Win32
		{5F46CA1C-88BC-4E19-BB65-8686B453441D}.Release|Win32.ActiveCfg = Release|Win32
		{5F46CA1C-88BC-4E19-BB65-8686B453441D}.Release|Win32.Build.0 = Release|Win32
		...

	EndGlobalSection

Next there is a little section that determines if in the IDE the solution itself will have a node in the tree or if it's just going to be a list of projects/folders:

	GlobalSection(SolutionProperties) = preSolution
		HideSolutionNode = FALSE
	EndGlobalSection

The last section specifies the nesting of the projects inside folders. It is a clever way to specify arbitrarily nested structure in a linear format. Both the parent and the child are specified using their GUIDs, so it's pretty difficult to figure out what project is in what folder. Of course, this file is not intended for direct viewing:

	GlobalSection(NestedProjects) = preSolution
		{5F46CA1C-88BC-4E19-BB65-8686B453441D} = {64EECA44-A21D-4FB3-8C2C-3D3B81EE2F3C}
		{48933983-2311-4966-A33E-06B47FE88B6A} = {64EECA44-A21D-4FB3-8C2C-3D3B81EE2F3C}
		{6D1F69E3-575B-4BB9-8B5F-D295916A2C3B} = {64EECA44-A21D-4FB3-8C2C-3D3B81EE2F3C}
		{B5183A0D-18E4-4288-8DB0-60183460677E} = {8A47B373-446F-42A7-83BB-EFED3017940F}
		{88AD54BE-4316-4DFB-965E-4369A2910DF8} = {55B446A3-CAA3-4EFB-BA53-2232048BF417}
		{D0736B61-D7AE-4B50-99FF-1AC604AF83D1} = {0C7A17A3-B93D-43AE-A166-1DDAAE8E2B46}
		{7A0F57A3-00B8-4879-BBE1-318E3FC0A526} = {0C7A17A3-B93D-43AE-A166-1DDAAE8E2B46}
		{C99C4A67-8323-4CD7-B049-354E019994C8} = {0C7A17A3-B93D-43AE-A166-1DDAAE8E2B46}
	EndGlobalSection

Let's try and follow one such nesting relation:

   {7A0F57A3-00B8-4879-BBE1-318E3FC0A526} = {0C7A17A3-B93D-43AE-A166-1DDAAE8E2B46}

The first GUID belongs to the utils project.

Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "utils", "hw\utils\utils.vcproj", "{7A0F57A3-00B8-4879-BBE1-318E3FC0A526}"
EndProject

By the way, the GUID in Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") denotes the project type (static library in this case). The project's GUID is the one following the project file path..

The second GUID belongs to the hw folder:

Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "hw", "hw", "{0C7A17A3-B93D-43AE-A166-1DDAAE8E2B46}"
EndProject

So, the nesting relation says that the utils project is contained in the hw folder.