Использовать цепочку инструментов .NET Core для проектов клиентов - PullRequest
Новая
       25

Использовать цепочку инструментов .NET Core для проектов клиентов

0 голосов
/ 14 февраля 2019

Задача: Мне нужно управлять проектами клиентов.У нас есть частный репозиторий NuGET, на котором размещен загрузчик (Company.Core.Cmd, предназначенный для netcoreapp2.0) и некоторые модули (например, Company.Component.A и Company.Component.B, предназначенные для netstandard2.0).Каждый проект клиента состоит из комбинации загрузчика и некоторых модулей и добавляет несколько статических файлов (например, конфигурацию).

Вопрос: Является ли следующее решение лучшим способом решения этой проблемы илиесть лучший способ записать csproj таким образом, чтобы конфигурация времени выполнения генерировалась для Company.Core.Cmd.Есть ли какие-то properties, которые я пропускаю или использую Microsoft.NET.Sdk даже неправильную отправную точку?Может быть, использовать MSBuild напрямую без SDK или другого SDK?Это решение кажется мне обходным путем, поэтому я не совсем уверен в его использовании.

Справочная информация: В настоящее время мы используем dotnet publish на Company.Core.Cmd, чтобы получить работоспособныйсреда, которая содержит app.deps.json и app.runtimeconfig.json.Кроме того, мы добавляем результаты dotnet publish необходимых модулей, которые могут привести к проблемам, если требуются разные версии зависимостей.

Одним из обходных путей, который мы пробовали, было клонирование Company.Core.Cmd.csproj и добавлениенеобходимые модули как PackageReference и делать dotnet publish на этом кастомном csproj.Это решает проблему, но потребует клонирования кода Company.Core.Cmd, который нам не нравится.

Возможное решение: Сегодня у меня возникла идея использовать цепочку инструментовсоздать отдельный csproj файл, подобный этому, и использовать для него dotnet publish: 

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <Version>0.0.1</Version>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <DebugType>None</DebugType>
    <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Company.Core.Cmd" Version="0.1.0" />
    <PackageReference Include="Company.Component.A" Version="0.1.0" />
    <PackageReference Include="Company.Component.B" Version="0.2.0" />
  </ItemGroup>

  <ItemGroup>
    <Content Include="config.bin" />
  </ItemGroup>

</Project>

Это работает в некоторой степени, разрешая все зависимости и создавая работоспособное решение.Но для этого проекта будут созданы файлы .deps.json и .runtimeconfig.json, а не Company.Core.Cmd.Работает переименование сгенерированных файлов в Company.Core.Cmd и удаление dll для этого проекта (у которого нет кода и, следовательно, нет точки входа).Это можно автоматизировать с помощью задачи после сборки и поместить в Sdk, чтобы упростить использование.

...