What's the purpose of this string in my Visual Studio *.sln file?

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

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

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

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

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

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

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

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

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

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

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

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

and it still works fine.

From MSDN:

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

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

For example:

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