Как правильно упаковать распределенный пользовательский инструмент Nuget, который генерирует исходный код как часть сборки - PullRequest
Новая
       38

Как правильно упаковать распределенный пользовательский инструмент Nuget, который генерирует исходный код как часть сборки

1 голос
/ 25 апреля 2019

Благодаря этой замечательной статье Нейта МакМастера, я знаю, как упаковать консольное приложение ядра .NET в пакет Nuget, который автоматически устанавливается в качестве (в данном случае, задачи сборки).

Чтобы проверить, все ли работает, я просто попросил свой инструмент написать публичный класс C #.

Вот полный и работающий пример на Github .

Однако файл, который добавляет мой пользовательский инструмент, на самом деле не является частью сборки (первым, который фактически генерирует файл), и поэтому введенный класс не находится в сборке после первой сборки (см. Строку 38 * 1013). * здесь ). Однако, поскольку базовые проекты .NET теперь автоматически включают все файлы .cs вместе с проектом, он создает новый класс в выходных данных при последующих сборках (см. Строку 57 здесь ).

Сгенерированные файлы не уходят в чистоту, хотя и, как правило, не ведут себя так, как то, что выводит задача MSBuild. Однако, поскольку exec происходит в файле целей, мы должны иметь доступ ко всем механизмам, чтобы это произошло. Итак, мой вопрос:

Как правильно запустить пользовательский инструмент сборки (консольное приложение), который должен изучить проект, его файлы и сгенерировать исходный код (предпочтительно в формате obj /, как, скажем, <foo>.g.cs, который компилируется в результирующую сборку как часть одиночная сборка? В идеале этот сгенерированный файл (ы) также не должен появляться в обозревателе решений.

Помощь!

1 Ответ

1 голос
/ 26 апреля 2019

При создании промежуточного файла (CustomTool.g.cs) в промежуточной папке (вам необходимо разрешить его, см. Пример в библиотеке переустановки: https://github.com/reactiveui/refit/blob/5b4e14aaf8a1fcc27396b7c08171d100aba1b97d/Refit/targets/refit.targets#L11);, вам необходимо явно добавить его как элемент компиляции .

Взять файл с примерами целей (https://github.com/aniongithub/CustomTool/blob/master/CustomTool/RunCustomTool.targets#L13):

<Project>
  <PropertyGroup>
    <IntermediateOutputPath Condition="$(IntermediateOutputPath) == '' Or $(IntermediateOutputPath) == '*Undefined*'">$(MSBuildProjectDirectory)obj\$(Configuration)\</IntermediateOutputPath>

    <!-- Command to invoke CustomTool -->
    <CustomTool>dotnet "$(MSBuildThisFileDirectory)/netcoreapp2.2/CustomTool.dll"</CustomTool>

    <!-- Other variables  -->
    <CustomVariable>"$(MSBuildProjectDir)"</CustomVariable>
  </PropertyGroup>

  <Target Name="CustomTool" BeforeTargets="CoreCompile" DependsOnTargets="PrepareForBuild">
    <Exec Command="$(CustomTool) $(ProjectPath) $(IntermediateOutputPath)CustomTool.g.cs" />

    <!-- add generated file as a compile item, otherwise it won't get picked up -->
    <ItemGroup Condition="Exists('$(IntermediateOutputPath)\CustomTool.g.cs')">
      <Compile Include="$(IntermediateOutputPath)\CustomTool.g.cs" />
    </ItemGroup>
  </Target>
</Project>
...