[ACCEPTED]-What's the purpose of this string in my Visual Studio *.sln file?-visual-studio-2008

The {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} line indicates that the Test2008 project 21 has a declared dependency (set up via the 20 Project Dependencies dialog in VStudio) on 19 the project with the unique identifier 82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8. You 18 should be able to find a project with that 17 same identifier in the same .sln file.

As 16 for why the odd syntax of the line, I have 15 no insider knowledge of the .sln file format. However, based 14 on observation of other ProjectSection extracts 13 in .sln files, I would have to guess that 12 the .sln parser used by Visual Studio historically 11 assumed that the ProjectSection lines will 10 be in a key = value format, with key uniqueness enforced 9 within any given section. I would also 8 guess that the folks who implemented the 7 project dependency functionality decided 6 that, rather than mucking with the parser, it 5 would be simpler to use projectId = projectId for their section 4 lines since the keys are meaningless to 3 them, but they are guaranteed to be unique 2 if only one dependency from project A to 1 project B is otherwise enforced.

It seems that this redundant syntax is one 38 of the quirks required by MSBuild to recognize 37 a project's dependency:

It appears that Visual 36 Studio keeps the dependencies in two ways, only 35 one of which is read by MSBuild. I see that 34 because I still can specify dependencies 33 in GUI, copy solution to other machine 32 and build it with VS in correct order. -Victor Sergienko

As 31 for why this "superfluous equation statement" is 30 required, it seems that assigning a project's 29 guid to its own guid is a workaround for 28 an issue with MSBuild 4.0 that causes MSBuild 27 to not recognize or respond to certain project 26 dependencies listed in a solution (.sln) file, or 25 to build the dependencies out of order.

The 24 screwed up "{x}={x}" syntax you're 23 asking about is a variation of the standard 22 MSBuild syntax for referencing a project 21 (i.e. the example @Sergio's answer).

Apparently, embedding 20 the dependency declaration in a ProjectSection 19 block in conjunction with a self-named dependency 18 GUID causes MSBuild to change the build 17 order of the depended-upon project, but 16 doesn't actually add another reference to 15 it.

There's a discussion on Microsoft Connect wherein this workaround is 14 discussed. In it, Dan from Microsoft suggests 13 a cleaner workaround for this MSBuild glitch 12 in his 2nd post on the page, and also mentions 11 the fix you're asking about:

However, you 10 can create a project reference that only [affects] the build order without 9 [actually] adding [any runtime] reference. [Modify 8 the dependent .csproj or .vbproj to] look like this; note the metadata 7 element:

<ProjectReference Include="... foo.csproj">
  <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>

[...] That fixes the ordering, as 6 now LibraryProject will wait on CodeGeneratingProject, but 5 its build will otherwise not be affected. I 4 can tidy up by removing the dependency in 3 the solution file as well - removing these 2 lines, which are now unnecessary:

ProjectSection(ProjectDependencies) = postProject
    {B79CE0B0-565B-4BC5-8D28-8463A05F0EDC} = {B79CE0B0-565B-4BC5-8D28-8463A05F0EDC}
EndProjectSection

and it 1 still works fine.

From MSDN:

This statement contains the unique project GUID and the 10 project type GUID. This information is used 9 by the environment to find the project file or 8 files belonging to the solution, and the 7 VSPackage required for each project.

The 6 project GUID is passed to IVsProjectFactory 5 to load the specific VSPackage related to 4 the project, then the project is loaded 3 by the VSPackage. In this case, the VSPackage that 2 is loaded for this project is Visual Basic.

For 1 example:

Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "Project1", "Project1.vbproj", "{8CDD8387-B905-44A8-B5D5-07BB50E05BEA}" EndProject

Lines after ProjectSection(ProjectDependencies) = postProject specifies dependency list - which 8 project depends on which. (Can be seen in 7 Solution > Properties > Project Dependencies).

If 6 you want to "decrypt" more what 5 is happening inside, take a look at following 4 project:

https://sourceforge.net/p/syncproj/code/HEAD/tree/

Here is .sln parser, you can check 3 Solution.cs, search for "ProjectDependencies".

key 2 is always same as value, this is some sort 1 of file format issue.