Twórz pakiet NuGet automatycznie, w tym zależności, do których istnieją odwołania

Chcę uruchomić lokalne / wewnętrzne repozytorium NuGet . Myślę, że wymyśliłem, jak „ponownie wykorzystać” istniejące pakiety NuGet, włączając je do fałszywego projektu przy użyciu NuGet i skanując plik pakietu w celu pobrania moich .nupkgplików zapisanych lokalnie w pamięci podręcznej , ale ...

Jak utworzyć pakiet NuGet ( .nupkg) z projektu, automatycznie uwzględniając wszystkie dll zależności, a nie tylko te, które zostały pobrane za pośrednictwem NuGet?

Konkretnie:

1. Utwórz rozwiązanie
2. Dodaj nowy projekt
3. Dodaj odniesienia do różnych .dllplików / innych projektów <- to jest brakująca część
4. Dodaj pakiety NuGet za pośrednictwem Menedżera pakietów / cmdline / cokolwiek
5. coś automatycznie tworzy plik.nupkg

Z tego, co odkryłem, powinieneś robić takie rzeczy

• ręcznie edytuj .csprojplik, aby dodać <BuildPackage>true</BuildPackage>do niego zależności
• ręcznie utwórz .nuspecplik i ręcznie wymień swoje zależności ( podobne? )
• ręcznie uruchomić nuget packna .nuspecpliku

Ale wszystko jest ręczne, co jest głupie. Nawet rozwiązania półautomatyczne są nadal niewygodne lub w połowie ręczne:

• Twórz .nuspecszablony - nie wydaje się zawierać zależności, tylko metadane

• nuget za pośrednictwem zdarzenia kompilacji (krok # 5), który należy dodać ręcznie do każdego projektu i ma swoje własne dziwactwa :

  "$(SolutionDir).nuget\NuGet.exe" pack "$(ProjectPath)" -Properties Configuration=Release
  move /Y *.nupkg "$(TargetDir)"
  

Zadowolę się czymś, co automatycznie tworzy .nuspecmanifest na podstawie odwołań do projektu. Następnie teoretycznie + zdarzenie kompilacji nuget można umieścić w pakiecie build-project / nuget, co naprawdę chcę zobaczyć.

Twój punkt 3 ( Dodaj odniesienia do różnych plików .dll / innych projektów <- to jest brakująca część ) naprawdę zawiera dwa różne problemy: (1) dodaj odniesienia do różnych plików dll i (2) dodaj odniesienia do innych projektów w to samo rozwiązanie.

Numer (2) tutaj otrzymał dodatkową obsługę od wersji NuGet 2.5 . Możesz dodać opcję dołączania odwołań do innych projektów w tym samym rozwiązaniu podczas tworzenia pakietu NuGet dla projektu:

nuget pack projectfile.csproj -IncludeReferencedProjects

Jeśli projectfile.csprojodwołuje się do innych projektów w rozwiązaniu, które również są ujawniane jako pakiety NuGet, pakiety NuGet tych projektów zostaną dodane jako zależności. Jeśli odwołuje się do projektów w rozwiązaniu, które nie ujawniają się jako pakiety NuGet, ich biblioteki DLL zostaną uwzględnione w tym pakiecie NuGet.

Jeśli chodzi o (1), jeśli często dodajesz biblioteki DLL do projektów, które nie są dostępne jako pakiety NuGet, możesz po prostu utworzyć własne (wewnętrzne) pakiety NuGet z tymi plikami. Jeśli następnie dodasz te biblioteki DLL jako pakiet NuGet zamiast plików bezpośrednio, ten pakiet NuGet będzie zależnością w pakiecie NuGet projektu.

W przypadku innych pracowników Google możesz użyć tego, jeśli używasz pliku NuGet.targets do uruchamiania pakietu NuGet:

<Target Name="PrePackage" BeforeTargets="BuildPackage">
  <PropertyGroup>
    <BuildCommand>$(BuildCommand) -IncludeReferencedProjects</BuildCommand>
  </PropertyGroup>
</Target>

Sprawdź to!

Rozwiązanie, które znalazłem to rozszerzenie do Visual Studio: https://visualstudiogallery.msdn.microsoft.com/fbe9b9b8-34ae-47b5-a751-cb71a16f7e96/view/Reviews

Wystarczy dodać nowy projekt o nazwie Pakiet NuGet Pakiet NuGet

Następnie dodajesz ciekawe projekty do referencji i BOOOM !! Wszystkie zależności i katalogi plików są dodawane automatycznie. Jeśli chcesz zmodyfikować dane NuSpec, kliknij bezpośrednio w projekcie i przejdź do Właściwości, a następnie zmodyfikuj, co chcesz. Wygenerowane NuSpec i nupkg będą w folderze obj nowego projektu. Mam nadzieję, że to pomoże ;).

Znalazłem dobrze napisany artykuł na ten temat. Mam ten sam problem z niektórymi pakietami, które mają hierarchię zależności i do tej pory przesyłałem każdy z nich jako oddzielny pakiet NuGet (co jest. Marnowaniem. Czasu)

Właśnie przetestowałem rozwiązanie znalezione tutaj: https://dev.to/wabbbit/include-both-nuget-package-references-and-project-reference-dll-using-dotnet-pack-2d8p

Po zbadaniu pakietu NuGet za pomocą Eksploratora pakietów NuGet biblioteki DLL utworzone przez przywoływane projekty są rzeczywiście obecne. Mam zamiar przetestować, przesyłając ten pakiet do NuGet i testując go.

Oto moje źródło na wypadek, gdyby było pomocne: https://github.com/jchristn/NuGetPackTest

Oraz testowy pakiet NuGet: https://www.nuget.org/packages/NuGetPackTest/1.0.0

Wydaje się, że rozwiązanie działa dobrze. Nie wiem, jak to będzie wyglądać, gdy będą warstwy odniesień, jestem pewien, że może stać się naprawdę owłosione i naprawdę szybko.

.csproj z biblioteki NuGetPackTest, która odwołuje się do projektu TestLibrary (części usunięte w celu zwięzłości)

<Project Sdk="Microsoft.NET.Sdk">
 
  <PropertyGroup>
    <TargetFrameworks>netstandard2.0;netcoreapp3.0;netcoreapp3.1;net461</TargetFrameworks>
    ...
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>

    <!-- added this line -->
    <TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);CopyProjectReferencesToPackage</TargetsForTfmSpecificBuildOutput>
  </PropertyGroup>

  <ItemGroup>

    <!-- modified this ProjectReference to include the children ReferenceOutputAssembly and IncludeAssets -->
    <ProjectReference Include="..\TestLibrary\TestLibrary.csproj">
      <ReferenceOutputAssembly>true</ReferenceOutputAssembly>
      <IncludeAssets>TestLibrary.dll</IncludeAssets>
    </ProjectReference>
  </ItemGroup>

  <!-- added this section -->
  <Target DependsOnTargets="ResolveReferences" Name="CopyProjectReferencesToPackage">
    <ItemGroup>
      <BuildOutputInPackage Include="@(ReferenceCopyLocalPaths->WithMetadataValue('ReferenceSourceTarget', 'ProjectReference'))"/>
    </ItemGroup>
  </Target>
  
</Project>