Как используется dirs.proj?

Я боюсь, что, возможно, я задам очень глупый вопрос, но я не могу найти ничего, что делает это ясным. Я обычно работаю над более мелкими приложениями, но теперь я работаю над более крупным, имеющим несколько сборок в базовой линии и несколько сборок для домена линейки продуктов (с еще большим количеством). Я хотел бы управлять сборкой, настраивая MSBuild. Я провел много онлайн-исследований (особенно с несколькими статьями MSDN, которые я нашел), и теперь чувствую себя достаточно осведомленным, чтобы быть опасным.

Я понимаю, что в csharp файл *.csproj может быть выгружен и изменен с помощью свойств, элементов и целей для управления процессом сборки. Я также понимаю, что я могу импортировать свой собственный файл целей, чтобы помочь разделить и организовать. В этой ссылке хотя (https://msdn.microsoft.com/en-us/magazine/dd483291.aspx) многоуровневая сборка проекта организована с файлами node -level dirs.proj. Это меня сбивает с толку и подняло несколько вопросов, на которые я не могу найти ответа:

  • В чем разница в файле *.proj и *.csproj?
  • Может ли *.proj быть настроен в VS для загрузки Build с F6 или использовать это требует только командной строки? (т.е. msbuild dirs.proj/t: Build).
  • Загружается ли dirs.proj автоматически? Если это так, мое исследование не работает корректно, но оно работает с командной строкой.
  • Или я пропущу что-то с помощью "dirs.proj". Может быть, это просто имя подстановки для одного из файлов проекта .csproj? Если бы это было так, хотя не было бы необходимости в корневом каталоге node dirs.proj, который из того, что я могу сказать, не имеет связанного с ним фактического проекта.

В любом случае, я видел, что dirs.proj упоминается в нескольких форумах по вопросам, но нет, где я могу найти, как он загружается или используется в VS (за пределами командной строки командной строки, которая кажется необоснованной, если это используется для организации сборки но сборке на самом деле не потребуется огромное количество времени). Я надеюсь, что кто-то может помочь мне достичь этого момента а-ха с этим.

Спасибо заранее.

Ответы

Ответ 1

Dirs.proj - это соглашение MSBuild, обычно используемое при работе с очень большими исходными деревьями ( > 20 проектов). Я работал с инженерами Microsoft в предыдущей компании, и соглашение dirs.proj похоже на то, что Microsoft разработала и использует внутренне для управления очень большими деревьями-источниками.

Очень хорошей ссылкой для реализации является проект Python Tools for Visual Studio в CodePlex.

Ссылка которую вы поделили Сайедом Ибрагимом Сашими, является очень хорошим объяснением аргументации парадигмы msbuild, но она не очень хорошо показывает практический пример того, как это работает. Проект Python Tools является выдающейся ссылкой для этого.

Идея использования этой парадигмы проста. Я бы предпочел, чтобы большинство разработчиков программного обеспечения .NET работали над проектами с ограниченным масштабом, которые не занимаются более чем 5-10 проектами одновременно, и управляют этими проектами в Visual Studio через файлы решений (.sln), Они могут даже поручить своей системе сборки запускать сборки на .sln. Это прекрасно работает, пока вы не начнете думать о масштабировании вашего продукта или его объединении с чем-то большим, например, с платформой со многими, многими проектами. Файлы решений не являются файлами MSBuild и, как таковые, они не расширяемы, как MSBuild, и они подвергаются серьезным штрафам за производительность при работе с большим количеством проектов.

С точки зрения MSBuild, dirs.proj поддерживает файлы Visual Studio.sln. Разница, однако, заключается в том, что dirs.proj не просто включают .csproj(и тому подобное) как .sln, скорее, они могут включать в себя исходные поддеревья (например, другие вложенные dirs.proj). Таким образом, создание корня dirs.proj может привести к созданию всего дерева исходных текстов или построению вложенного dirs.proj приведет к созданию этого поддерева.

Поэтому парадигма побуждает вас взглянуть на ваш источник как на серию взаимозависимых узлов, организованных в функции или области продуктов. Таким образом, инженеры могут работать с разными исходными поддеревами в очень больших проектах без необходимости иметь дело со всем исходным деревом, как это было бы с решением VS.

Использование этой парадигмы также несет определенные преимущества, которые не связаны с .sln файлами. Например, если один проект ссылается на проект из другого, отдельного поддерева, msbuild будет создавать эту ссылку сначала автоматически. Кроме того, ваши исходные узлы могут иметь свои собственные настройки сборки, позволяя им динамически строить, используя разные параметры сборки на основе сценария сборки. Например, по одному сценарию для источника данных SharePoint требуется упаковка WSP, поддерево С# должно быть построено без .pdb, поддерево DB должно генерировать dacpacs, и все дерево исходных текстов должно подписать свои сборки с помощью myCorp.snk и установить сборку вывод в каталог $(buildRoot)\Output.

dirs.proj не открывается через визуальную студию - они построены на командной строке с использованием msbuild. Единственная причина боли в том, что файлы должны быть обработаны вручную.

Итак, длинный ответ коротко взгляните на проект Python Tools и посмотрите, как они используют dirs.proj. Обратите внимание, как все дерево исходных текстов имеет общие настройки, управляемые Common.Build.settings, и как свойства msbuild в этом файле .settings используются в различных файлах .csproj.