关于Visual Studio * .sln文件格式的问题

我正在使用文本编辑器手动编辑我的* .sln文件。我感到困惑的下面几行：关于Visual Studio * .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}点

声明？它看起来完全是多余的。

来源

2011-04-12 smwikipedia

如果你拿出来会发生什么？ – 2011-04-12 03:14:59

看来，这多余的语法是的MSBuild认识到项目的依赖关系所需的怪癖之一：

看来，Visual Studio中保持的依赖有两种方式，只有一个其中读由MSBuild。我看到，因为我仍然可以在GUI中指定依赖关系，将解决方案复制到其他机器并使用VS以正确的顺序构建它。 - Victor Sergienko

至于为什么需要这种“多余的方程声明”，似乎分配项目的GUID给自己的GUID是用的MSBuild 4.0的问题而导致的MSBuild不解决方法识别或响应解决方案（.sln）文件中列出的某些项目依赖项，或者不按顺序构建依赖项。

你所问的搞砸的“{x} = {x}”语法是用于引用项目的标准MSBuild语法的变体（例如@Sergio的答案）。

显然，将一个ProjectSection块中的依赖声明嵌入到一个自命名的依赖项GUID中会导致MSBuild更改依赖项目的构建顺序，但实际上并未向其添加其他引用。

有一个discussion on Microsoft Connect其中讨论此解决方法。在这里面，丹微软建议在他的页面上的第二个留言本的MSBuild毛刺一个更清洁的解决方法，并且还提到你问如何修正：

这正好解决了排序，因为现在LibraryProject将等待CodeGeneratingProject，但其构建不会受到影响。我可以通过删除的解决方案文件的依赖性，以及整理 - 删除这些线，现在没有必要：

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

，它仍然能正常工作。

来源

2011-04-25 01:33:12

从MSDN：

本声明包含独特项目GUID和项目类型 GUID。环境使用此信息来查找项目文件或属于解决方案的文件，和每个项目所需的VSPackage。

GUID传递给 IVsProjectFactory加载特定 VSPackage的项目相关的项目，然后该项目由 VSPackage的加载。在这种情况下，为此项目加载的VSPackage 是 Visual Basic。

例如：

项目（ “{F184B08F-C81C-45F6-A57F-5ABD9991F28F}”） = “PROJECT1”， “Project1.vbproj”，“{8CDD8387-B905-44A8 -B5D5-07BB50E05BEA}” EndProject

来源

2011-04-12 03:15:51

感谢您的回复但我理解您的示例中的陈述。令我困惑的是** ProjectSection **中多余的公式语句。 – smwikipedia 2011-04-12 03:40:44

+1为MSDN参考 – Mitch 2012-12-15 21:30:17

的{82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8}行表示Test2008项目已声明的依赖上项目（通过VStudio项目依赖关系对话框中设置）与唯一标识符82B9BEC0-C9CC-4423- B54F-61E3C4AF53D8。您应该能够在同一个.sln文件中找到具有相同标识符的项目。至于为什么这条线的奇怪语法，我没有.sln文件格式的内幕知识。但是，基于对.sln文件中其他ProjectSection提取的观察，我不得不猜测，Visual Studio使用的.sln解析器历来假定ProjectSection行将采用key = value格式，并且在任何给定部分内都强制执行密钥唯一性。我也猜测那些实现了项目依赖性功能的人决定，不要使用解析器，因为使用projectId = projectId作为他们的分区线会更简单，因为这些键对他们来说是没有意义的，但是如果他们保证是唯一的否则强制执行只有一个从项目A到项目B的依赖关系。

来源

2011-04-18 13:10:19

这正是我所寻找的信息，它是在解决方案文件中配置此信息的“Project Dependencies”对话框。似乎有点棘手，因为“Project References”也可以添加复选框以在此对话框中进行检查，但是您不会找到相应的“ProjectSection（ProjectDependencies）”条目。看起来我刚刚发现我们的团队在Visual Studio中使用了项目依赖项/引用项的混合。需要转换为仅使用项目引用。 – jxramos 2016-09-08 19:00:15

ProjectSection(ProjectDependencies) = postProject之后的行指定依赖项列表 - 哪个项目取决于哪个依赖项。（可以在Solution> Properties> Project Dependencies中看到）。

如果你想“解密”更里面是什么发生了，看看以下项目：

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

下面是的.sln解析器，你可以检查Solution.cs，搜索“ProjectDependencies ”。

键值总是相同，这是某种文件格式问题。

来源

2017-02-04 16:05:40 TarmoPikaro

谢谢。我会看看那个。我从不期望可以为此生成语法分析器。 – smwikipedia 2017-02-04 23:35:09

关于Visual Studio * .sln文件格式的问题

回答

相关问题