Можно ли ограничить область действия Directory.Build.Props одним решением Visual Studio? - PullRequest
0 голосов
/ 31 января 2020

У меня есть решение Visual Studio с более чем 100 проектами. Я хочу применить определенные настройки ко всем проектам, поэтому я использовал файл Directory.Build.Props, и он отлично работает. Однако после прочтения документации я только что понял, что все решения в подкаталогах также будут использовать эти настройки, но я не хочу влиять на эти решения, так как не поддерживаю их. Есть ли способ ограничить область действия файла Directory.Build.Props текущим каталогом или конкретным решением? (Возможно, вы можете настроить имя файла Props и импортировать его для конкретного решения?)

Например, рассмотрим структуру каталогов, организованную так:

/code/MySolutionFile.sln
/code/Project001/
/code/Project002/
/code/Project003/
...
/code/Project100/

/code/OtherStuff/OtherStuff.sln
/code/OtherStuff/ProjectA
/code/OtherStuff/ProjectB
/code/OtherStuff/[lots of other solutions somewhere in this directory tree]

Я поставил свой Файл Directory.Build.Props в каталоге /code, потому что я хотел бы определить настройки для всех проектов в /code/MySolutionFile.sln. Но я не хочу влиять на какие-либо другие решения в подкаталогах папки /code.

Если все остальное не удается, я думаю, что я мог бы создать пустой файл Directory.Build.Props и поместить его в каждый каталог, содержащий файл решения, за исключением того, к которому я хочу применить мой. (Но это похоже на последнее средство.)

Ответы [ 3 ]

1 голос
/ 10 февраля 2020

MSBuild поддерживает Conditions для многих типов элементов, включая PropertyGroup и отдельные свойства. В этом случае вам не нужен Choose-When - вы можете просто поставить условие на PropertyGroup или TreatWarningsAserrors напрямую.

1 голос
/ 03 февраля 2020

Есть ли способ ограничить область действия файла Directory.Build.Props текущим каталогом или конкретным решением? (Возможно, вы можете настроить имя файла Props и импортировать его для определенного решения?)

Directory.Build.Props будет действовать на xxxx.sln текущей папки, которая содержит много включенных xxxx.csproj файлы, а затем также действуют на xxxx.proj файлы всех подпапок. Это будет go вниз на один шаг за раз для любого xxx.proj файла, который он найдет, и он разработан таким образом. Вы можете увидеть область поиска .

Поскольку ваш обходной путь работает хорошо, но он немного сложен, или вы можете попробовать мое решение, если хотите:

Обходной путь

Пожалуйста, создайте папку с именем MyStuff в папке код и затем поместите Project001 --- Project100 в эту папку. После этого поместите файл Directory.Build.Props в папку MyStuff. При этом файл будет влиять только на Project001 --- Project100 .

Надеюсь, он может вам помочь.

0 голосов
/ 06 февраля 2020

Изменение моего файла Directory.Build.props таким образом решает мою задачу:

<Project>
  <PropertyGroup Condition="$(SolutionFileName) == 'MySolution.sln'">
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  </PropertyGroup>
</Project>

Это работает путем установки PropertyGroup для условного запуска правил. (Обратите внимание, что условие может также применяться к указанным c правилам, а не к группе.) В этом случае я смог использовать имя файла решения, чтобы ограничить область действия этого правила моим желаемым решением, не затрагивая другие.

Одно предостережение: в документации утверждается, что переменные решения доступны только при использовании в IDE. Однако при моем ограниченном тестировании правила также правильно применяются, когда я использую msbuild из командной строки, например: msbuild.exe MySolution.sln

Я тестировал его как из командной строки VS Developer Developer, так и из обычной команды Windows Запрос, и оба по-прежнему правильно читают переменную $(SolutionFileName).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...