Вопрос о формате 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

Строка {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} указывает, что проект Test2008 имеет объявленную зависимость (устанавливается через диалоговое окно «Зависимости проекта» в VStudio) от проекта с уникальным идентификатором 82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8.Вы должны быть в состоянии найти проект с тем же идентификатором в том же файле .sln.

Что касается нечетного синтаксиса строки, у меня нет никаких внутренних знаний о формате файла .sln.Однако, основываясь на наблюдении за другими выдержками ProjectSection в файлах .sln, я должен был предположить, что синтаксический анализатор .sln, используемый Visual Studio, исторически предполагал, что строки ProjectSection будут иметь формат key = value, с уникальностью ключа, применяемой в любом заданномраздел.Я также предположил бы, что люди, которые реализовали функциональность зависимости проекта, решили, что вместо того, чтобы связываться с парсером, было бы проще использовать projectId = projectId для их строк раздела, так как ключи для них не имеют смысла, но они гарантированно будутуникально, если только одна зависимость от проекта A к проекту B будет принудительно применена.

Answer 2

Кажется, что этот избыточный синтаксис является одной из причуд, требуемых MSBuild для распознавания зависимости проекта:

Похоже, что Visual Studio сохраняет зависимости двумя способами, только один из которых читаетсяот MSBuild.Я вижу, что, поскольку я все еще могу указывать зависимости в графическом интерфейсе, скопировать решение на другую машину и собрать его с VS в правильном порядке.- Виктор Сергиенко

Что касается , почему требуется это "лишнее утверждение уравнения", кажется, что назначение руководства проекта дляего собственный guid - это обходной путь для проблемы с MSBuild 4.0, из-за которой MSBuild не распознает или не реагирует на определенные зависимости проекта, перечисленные в файле решения (.sln), или строит зависимости вне порядка.

испорченный синтаксис "{x} = {x}", о котором вы спрашиваете, является разновидностью стандартного синтаксиса MSBuild для ссылки на проект (например, ответ @ Sergio).

По-видимому, встраивание объявления зависимостив блоке ProjectSection в сочетании с одноименным GUID зависимости заставляет MSBuild изменить порядок сборки зависимого проекта, но фактически не добавляет к нему другую ссылку.

Есть обсуждение в Microsoft Connect , где обсуждается этот обходной путь.В нем Дэн из Microsoft предлагает более четкое решение этой проблемы MSBuild во втором посте на странице, а также упоминает исправление, о котором вы спрашиваете:

Однако вы можете создать ссылку на проект.что только [влияет] на порядок сборки без [на самом деле] добавления ссылки [любая среда выполнения].[Изменить зависимых .csproj или .vbproj, чтобы выглядеть следующим образом;обратите внимание на элемент метаданных:

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

[...] Это исправляет порядок, поскольку теперь LibraryProject будет ожидать CodeGeneratingProject, но в противном случае его сборка не будет затронута.Я могу привести в порядок, удалив также зависимость в файле решения - убрав эти строки, которые теперь не нужны:

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

, и все равно работает нормально.

Answer 3

С MSDN :

Этот оператор содержит уникальный GUID проекта и тип проекта GUID.Эта информация используется средой для поиска файла проекта или файлов, относящихся к решению, и VSPackage, требуемого для каждого проекта.

GUID проекта передается в IVsProjectFactory для загрузки конкретного VSPackage, связанного с проектом, затем проект загружается VSPackage.В этом случае VSPackage, загружаемый для этого проекта, является Visual Basic.

Например:

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

Answer 4

Строки после ProjectSection(ProjectDependencies) = postProject определяет список зависимостей - от какого проекта зависит. (Можно увидеть в разделе «Решение»> «Свойства»> «Зависимости проекта»).

Если вы хотите «расшифровать» больше того, что происходит внутри, взгляните на следующий проект:

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

Вот парсер .sln, вы можете проверить Solution.cs, найти «ProjectDependencies».

Ключ

всегда совпадает со значением, это своего рода проблема с форматом файла.