Возможно ли использовать как локальный репозиторий NuGet, так и удаленный репозиторий

Я конвертировал наши библиотечные проекты в пакеты NuGet и размещал их на внутреннем фиде NuGet. Это отлично работает и сократило разработчиков, создавая вспомогательные классы и "изобретая колесо". Другим огромным плюсом является то, что другие команды теперь могут потреблять "выпущенные" библиотеки из наших проектов. В основном это была огромная победа.

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

Есть ли способ, чтобы локальные сборки собирались из локального репозитория? Я начал работу над заданием после сборки для библиотек, которые создают файлы локальных пакетов. Используя NuGet.config, я думаю, что я смогу скрыть некоторые репозитории, а затем замаскировать файлы конфигурации на сервере сборки. Моя теория заключается в том, что при использовании локальной сборки локальный репозиторий должен быть поднят, а на сервере сборки будет использоваться фид.

Возможно ли это? Есть ли еще кто-нибудь, кто документировал, как это сделать?

Вот задача после сборки, которую я использую для создания локальных пакетов:

  <PropertyGroup>
    <PackOutputDir>$([System.IO.Path]::Combine($(SolutionDir), "..\Prerelease"))</PackOutputDir>
    <BuildSpecCommand>$(NuGetCommand) spec $(ProjectFileName) -force -NonInteractive -Verbosity detailed</BuildSpecCommand>
    <PackCommand>$(NuGetCommand) pack $(ProjectFileName) -OutputDirectory "$(PackOutputDir)"</PackCommand>
  </PropertyGroup>
  <Target Name="AfterBuild" Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <Exec Command="$(BuildSpecCommand)" LogStandardErrorAsError="true" Condition=" '$(OS)' == 'Windows_NT' " />
    <Exec Command="$(PackCommand)" LogStandardErrorAsError="true" Condition=" '$(OS)' == 'Windows_NT' " />
  </Target>

Я поместил этот NuGet.config в корень нашего командного проекта. Этот файл скрывается на сервере сборки:

<configuration>
  <packageSources>
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
    <add key="TestSource" value="Source\Prerelease" />
  </packageSources>
  <disabledPackageSources>
    <add key="LocalNuGetFeed" value="LocalNuGetFeed" />
  </disabledPackageSources>
  <activePackageSource>
    <add key="All" value="(Aggregate source)"  />
  </activePackageSource>
</configuration>

Здесь NuGet.config, который я разместил в папке, которую нужно получить в иерархии на сервере сборки:

<configuration>
  <packageSources>
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
    <add key="LocalNuGetFeed" value="http://team2:12345/nuget" />
  </packageSources>
  <disabledPackageSources>
  </disabledPackageSources>
  <activePackageSource>
    <add key="All" value="(Aggregate source)"  />
  </activePackageSource>
</configuration>

Обновление Основываясь на предоставленном ответе, я изменил файл nuget.targets. В идеале я бы не хотел этого делать, но если это лучший способ достичь того, что я хотел бы выполнить, тогда я прекрасно разбираюсь в этом типе редактирования.

  <ItemGroup Condition=" '$(PackageSources)' == '' And '$Configuration' == 'Release'">
    <PackageSource Include="https://nuget.org/api/v2/" />
    <PackageSource Include="http://team2:12345/nuget/" />
  </ItemGroup>
  <ItemGroup Condition=" '$(PackageSources)' == '' And '$Configuration' != 'Release'">
    <PackageSource Include="https://nuget.org/api/v2/" />
    <PackageSource Include="C:\temp\NuGet\Prerelease" />
  </ItemGroup>

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

Правильно ли это?

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

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

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

Каково общее мнение об этом подходе?

Ответ 1