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

Question

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.

What happens if you take it out? – Michael Burr Apr 12 '11 at 03:14 — Michael Burr, Apr 12 '11 at 03:14

score 30 · Answer 1 · answered Apr 18 '11 at 13:10

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.

That's exactly the sort of information I was looking for, it is the `Project Dependencies` dialog that configures this information in the solution file. Seems a bit tricky since `Project References` can also add checkboxes to be checked in this dialog, but you wont find the corresponding `ProjectSection(ProjectDependencies)` entry. Looks like I just discovered our team is using a mixture of project dependency/references stuff in Visual Studio. Going to need to convert to using project references only. — jxramos, Sep 08 '16 at 19:00

score 27 · Accepted Answer · edited Apr 10 '19 at 23:59

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.

This answer gets some things incorrect. Visual Studio SLN files are their own file format and are not part of MSBuild. To support "building" an SLN, MSBuild actually scrapes the SLN for the bits of interest and generates a 'meta project' in MSBuild's language/format. The use of GUIDs and the `{x}={x}` syntax is not MSBuild. A project's dependencies should be added to the project file. Adding a "Project Dependency" in the SLN doesn't add a dependency to the project despite the name. What it does do, as described near the end of the answer, is influence the build order. — Jonathan Dodds, Jul 02 '23 at 17:17
@JonathanDodds I answered this 12 years ago so I'm sure it's outdated now, and might have been incorrect then. A new answer from you would be appreciated, or you're welcome to edit my answer. — Michael Hoffmann, Jul 03 '23 at 20:25

score 6 · Answer 3 · edited Jun 20 '20 at 09:12

6

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

edited Jun 20 '20 at 09:12

Community

1
1

answered Apr 12 '11 at 03:15

Only Bolivian Here

35,719
63
161
257

Thanks for your reply But I understood the statement in your example. What confuses me is the superfluous equation statement within **ProjectSection**. – smwikipedia Apr 12 '11 at 03:40

score 1 · Answer 4 · answered Feb 04 '17 at 16:05

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.

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

4 Answers4

Linked