Недавно я пытался создать общую библиотеку кода на C# для взаимодействия с новым корпоративным решением для хранения документов. Решение для хранения документов фактически хранило метаданные о документе в локальной базе данных, но сохраняло сам документ в хранилище больших двоичных объектов Azure и сохраняло ссылку на большой двоичный объект в нашей базе данных. Чтобы взаимодействовать с этой службой, я создал довольно простой веб-API с несколькими конечными точками, которые выполняли некоторые операции CRUD. API был защищен с использованием идентификатора клиента / секрета клиента, предоставленного нашим Окта пример.

Моя главная цель с этой библиотекой, как и со всем общедоступным кодом, который я пишу, состояла в том, чтобы максимально упростить реализацию кода и взаимодействие с новым решением для хранения документов. Код, стоящий за этой общей библиотекой, предлагает метод быстрой настройки, который настраивает некоторые службы для внедрения зависимостей, и фабричный класс, который извлекает эти службы для разработчика, при этом обрабатывая аутентификацию в фоновом режиме, поэтому им не нужно было об этом думать. много. Этот код потенциально мог быть использован любой группой в нашей организации, поэтому простота была ключевым фактором, а также доступность.

Я решил создать самородок пакет кода, который мы могли бы разместить в нашем веб-канале nuget артефактов Azure. Если вы не знаете, что такое пакет nuget, это, по сути, ZIP-файл с расширением .nupkg, который содержит скомпилированные DLL-файлы и любые вспомогательные файлы, необходимые для общего кода.

Раньше я создавал пакеты nuget, но не так давно, и казалось, что некоторые вещи изменились с прошлого раза. После нескольких поисков в Google я смог собрать воедино то, что очень хорошо сработало, чтобы получить пакет nuget с .net 6, и решил поделиться здесь…

Пара требований, которые у меня были для пакета:

  1. Он должен быть частью конвейеров сборки в Azure и получить версию автоматической сборки.
  2. Ему нужен файл README, который появляется в Visual Studio с документацией по использованию кода.

Итак, сначала я создал файл nuspec, который по сути представляет собой файл, определяющий, что должно быть в пакете, и некоторые метаданные о самом пакете. Похоже на это…

файл nuspec

Части, на которые я хочу, чтобы вы обратили внимание,

<id>NHA.Document.Client</id>
<version>$version$</version>
...
<readme>README.md</readme>
<dependencies>...</dependencies>
<files>...</files>
Войти в полноэкранный режим

Выйти из полноэкранного режима

Поле id должно быть уникальным идентификатором. Если бы вы опубликовали это на необходим уникальный идентификатор.

Версия является динамической из-за параметра $version$, который мы передаем ей. Подробнее об этом чуть позже.

Зависимости — это любые другие пакеты nuget, на которые опирается этот код. В этом случае я использую Swashbuckle для некоторых аннотаций данных.

Раздел файлов, пожалуй, самый важный. Здесь вы должны перечислить файлы, которые необходимы для фактического использования клиентской библиотеки. Все файлы .dll, .pdb, скомпилированные для этой библиотеки, должны быть перечислены здесь. Кроме того, если вы хотите, чтобы при установке всплывал файл readme, вы должны указать его здесь. Значение src — это просто путь к файлу, в котором он существует. Поскольку это скомпилированный код, он будет помещен в подкаталог bin в соответствии с версией .Net, на которой вы работаете.

Примечание к документации README.
Я все еще немного запутался в этом, но я считаю, что дело в том, что если у вас есть файл readme.txt, он автоматически появится при установке. С файлом .txt вы как бы ограничены в том, насколько красиво вы можете его сделать. Если вам нужен хорошо отформатированный файл readme с уценкой, который будет отображаться на сайте nuget.org при его публикации, вам также потребуется этот файл в пакете и ссылка на него в теге файла nuspec.

Как только я создал файл nuspec и сохранил его в корне клиентской библиотеки как NHA.Document.Client.nuspec, я был готов к следующему шагу.

Следующей частью было изменение файла .csproj для клиентской библиотеки, которую я упаковывал. Похоже на это…

csproj-файл

Основная часть, на которую следует обратить внимание, это

<PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <NuspecFile>NHA.Document.Client.nuspec</NuspecFile>
    <NuspecProperties>version=$(PackageVersion)</NuspecProperties>
</PropertyGroup>
Войти в полноэкранный режим

Выйти из полноэкранного режима

В этом разделе говорится, где взять определение файла .nuspec для пакета, и устанавливается наша переменная $version$. В нашем случае мы собираемся получить версию из фактического идентификатора сборки и передать ее, когда мы используем дотнет пакет команда. Подробнее об этом через секунду…

Ниже есть еще один раздел … но, если честно, я не уверен, нужен ли он 🙂 … я не помню, чтобы добавлял это, и я не уверен, как он туда попал … в любом случае, вот это является.

<ItemGroup>
    <None Update="README.md">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      <Pack>True</Pack>
      <PackagePath>\</PackagePath>
    </None>
</ItemGroup>
Войти в полноэкранный режим

Выйти из полноэкранного режима

Теперь мы готовы упаковать его с помощью команды «dotnet pack». Нам нужно указать команду пакета на csproj и передать некоторые дополнительные аргументы.

dotnet pack NHA.Document.Client.csproj  -p:PackageVersion=2.0.5 -c Release
Войти в полноэкранный режим

Выйти из полноэкранного режима

Если я запущу эту команду в корне клиентского проекта, она найдет файл csproj, который затем указывает на файл nuspec. С помощью команды -p: мы можем передавать значения переменных. В этом случае мы передаем номер версии. Команда -c предназначена для использования в конфигурации сборки, в данном случае я использую Release. Вы можете запустить это из командной строки, если у вас установлен dotnet, или включить его в файлы сборки yml. В моем случае команда в моих файлах yml выглядит так…

--target=pack --build-arg VERSION="$(Build.BuildNumber)"
Войти в полноэкранный режим

Выйти из полноэкранного режима

С помощью этой команды мы получаем номер сборки из сборки, и она становится нашей версией пакета. Наш конвейер сборки запускается автоматически каждый раз, когда мы пиаримся в основной ветке.

Итак, вот как я собираю пакеты nuget из библиотеки классов dotnet 6. Вероятно, это не очень интересно для многих, но я знаю, что когда я работал над этим, я много искал в Google, пробовал и ошибался, надеюсь, это поможет любому, кто пытается сделать то же самое.