visual-studio - 这个字符串在我的 Visual Studio *.sln 文件中的用途是什么？

Question

我正在使用文本编辑器手动编辑我的 *.sln 文件。我对以下几行感到困惑:

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

这有什么意义

{82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8}

陈述？它看起来完全是多余的。

Answer 1

似乎这种冗余语法是 MSBuild 识别项目依赖项所需的怪癖之一:

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

至于为什么需要这个“多余的等式语句”，似乎将项目的 guid 分配给它自己的 guid 是解决 MSBuild 4.0 问题的一种解决方法，该问题导致 MSBuild 无法识别或响应解决方案 (. sln) 文件，或乱序构建依赖项。

您要问的搞砸的“{x}={x}”语法是用于引用项目的标准 MSBuild 语法的变体(即@Sergio 的答案示例)。

显然，在 ProjectSection 块中嵌入依赖声明并结合自命名依赖 GUID 会导致 MSBuild 更改依赖项目的构建顺序，但实际上并没有添加对其的另一个引用。

有一个 discussion on Microsoft Connect其中讨论了这种解决方法。在其中，来自 Microsoft 的 Dan 在他在页面上的第二篇文章中为这个 MSBuild 故障建议了一个更清晰的解决方法，并提到了您正在询问的修复:

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.