I am using a text editor to manually edit my *.sln file. I am confused about the following lines:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Test2008", "Tools\Test2008\Test2008\Test2008.csproj", "{00B5EBB2-FDA5-4B23-BDC5-27E9F82E7C69}"
ProjectSection(ProjectDependencies) = postProject
{82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8}
EndProjectSection
EndProject
What's the point of this
{82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8}
statement? It looks totally superfluous.
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.
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.
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
Lines after ProjectSection(ProjectDependencies) = postProject
specifies dependency list - which project depends on which. (Can be seen in Solution > Properties > Project Dependencies).
If you want to "decrypt" more what is happening inside, take a look at following project:
https://sourceforge.net/p/syncproj/code/HEAD/tree/
Here is .sln parser, you can check Solution.cs, search for "ProjectDependencies".
key is always same as value, this is some sort of file format issue.
