Nano Hash - криптовалюты, майнинг, программирование

Каскад msbuild Directory.build.props для каждого проекта?

Резюме: я хочу установить свойства в группах свойств на основе условий, которые присутствуют только в конце конвейера сборки, и я ищу способ решить эту проблему раньше.

У меня есть довольно простой файл Directory.build.props

<Project>

  <PropertyGroup>
    <MyMode>Default</MyMode>
  </PropertyGroup>

  <!-- This one overrides the default group above -->
  <PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
    <MyMode>Changed to Debug</MyMode>
  </PropertyGroup>

  <!-- This one is not applied -->
  <PropertyGroup Condition=" '$(TargetFrameworkVersion)' == 'v4.7.2' ">
    <MyMode>Framework</MyMode>
  </PropertyGroup>


  <Target Name="Stats" AfterTargets="Build">
    <Message Importance="High" Text="::::: Mode set to $(MyMode)" />
    <Message Importance="High" Text="::::: Target Framework set to $(TargetFrameworkVersion)" />
  </Target>

</Project>

И простая структура проекта

E:.
│   Directory.build.props
│   MSBuild_Test.sln
│
├───ConsoleAppNet
│       App.config
│       ConsoleAppNet.csproj
│       Program.cs
│
└───MSBuild_Test
        Class1.cs
        LibStandard.csproj

LibStandard — это стандартная библиотека .net, ConsoleAppNet — это проект .net framework, который также имеет зависимость сборки от LibStandard.

Когда я запускаю скрипт msbuild выше, я получаю этот вывод

  LibStandard -> E:\temp\MSBuild_Test\MSBuild_Test\bin\Debug\netstandard2.0\LibStandard.dll
  ::::: Mode set to Changed to Debug
  ::::: Target Framework set to v2.0
  ConsoleAppNet -> E:\temp\MSBuild_Test\ConsoleAppNet\bin\Debug\ConsoleAppNet.exe
  ::::: Mode set to Changed to Debug
  ::::: Target Framework set to v4.7.2

Как видите, вывод консоли должен был активировать группу свойств с условием, в результате которого MyMode становится Framework, но это не сработало. Этот никогда не совпадал:

  <PropertyGroup Condition=" '$(TargetFrameworkVersion)' == 'v4.7.2' ">
    <MyMode>Framework</MyMode>
  </PropertyGroup>

Есть ли хороший способ применить PropertyGroups во время загрузки на основе приведенного выше условия?

Я знаю, что могу разместить переопределения PropertyGroup в Target, например:

  <Target Name="TooLate" BeforeTargets="BeforeBuild" Condition=" '$(TargetFrameworkVersion' == 'v4.7.2' ">
    <PropertyGroup >
      <MyMode>Framework</MyMode>
    </PropertyGroup>
  </Target>

и он также выполняется правильно, но на данный момент я не могу установить другие важные переменные.

Мое намерение состоит в том, чтобы перенаправить каталоги вывода на основе различных условий. Когда я поставил $(OutputPath) в цель, было уже слишком поздно. Проект игнорирует этот вывод для всей сборки этого проекта:

  <Target Name="TooLate" BeforeTargets="BeforeBuild" Condition=" '$(TargetFrameworkVersion)' == 'v4.7.2' ">
    <PropertyGroup >
      <OutputPath>New_Output_Directory</OutputPath>
    </PropertyGroup>
  </Target>

Я даже могу повторить переменную OutputPath, и она указывает на правильное значение, но сборка использует старое значение и не перенаправляет вывод.

13.02.2020

Ответы:


1

Дай мне пять, я нашел решение для всех приближающихся Самуэлей, спрашивающих об одной и той же проблеме.

Быстрый ответ

Во время импорта Directory.build.props никакие другие свойства (например, TargetFramework) уже не импортированы и будут по умолчанию пустыми. Вот почему проверки на них терпят неудачу. Вместо этого используйте Directory.build.targets!

  • Directory.build.props импортировано очень раньше, что позволяет устанавливать свойства в начале
  • Directory.build.targets импортировано очень поздно, что позволяет настроить цепочку сборки

Ресурсы

Вот несколько очень полезных страниц о msbuild

Объяснение

Вот цитата из абзац на странице настройки (пока живы текущие документы...)

Импорт заказа

Directory.Build.props импортируется в Microsoft.Common.props очень рано, и свойства, определенные позже, для него недоступны. Поэтому избегайте ссылок на свойства, которые еще не определены (и будут оценены как пустые).

Directory.Build.targets импортируется из Microsoft.Common.targets после импорта файлов .targets из пакетов NuGet. Таким образом, он может переопределять свойства и цели, определенные в большей части логики сборки, но иногда вам может потребоваться настроить файл проекта после окончательного импорта.

Читая это, можно сделать вывод о целях несколько нечетким, но Directory.Build.targets — лучшее место для переопределения свойств и использования условных проверок.

13.02.2020
Новые материалы

Кластеризация: более глубокий взгляд
Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

Как написать эффективное резюме
Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

Как я автоматизирую тестирование с помощью Jest
Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..