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


83

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:

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ć.


Właśnie natknąłem się na to VS przedłużacza eyecatch.no/projects/nuget-package-template który Muszę zajrzeć do ...
drzaus

3
Pięć lat później specyfikacja lub pakiet nuget 4.x nadal nie mogą określić zależności.
StingyJack

Czy istnieje aktualizacja tego problemu? Czy nadal masz te problemy?
Dominic Jonas

Zrezygnowałem z tego jakiś czas temu, ale sprawdź NuProj, o czym informuje ta odpowiedź
drzaus

Ten problem nadal istnieje. :(
BrainSlugs83

Odpowiedzi:


75

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.


3
westchnienie nr 1 jest nadal zbyt ręczne jak na mój gust. W rzeczywistości „utwórz własny (wewnętrzny) pakiet NuGet z tymi plikami” jest tym, co próbuję zrobić - sednem tego pytania jest to, że chcę automatycznie umieścić pliki .dll inne niż NuGet w pakiecie NuGet. Nie przeglądaj i nie wyświetlaj ręcznie każdego pliku dll w pliku .nuspec, co chyba sugerujesz?
drzaus

Nie musisz oddzielnie określać każdej biblioteki DLL. Naprawdę wymagałoby to dużo pracy, gdybyś miał ich wiele . Podczas wyświetlania listy plików do dołączenia możesz użyć (rekurencyjnych) symboli wieloznacznych ( docs.nuget.org/docs/reference/… ), więc jeśli na przykład umieścisz wszystkie te biblioteki DLL w oddzielnym folderze, uwzględnienie będzie jednowierszowe Centrum handlowe.
Julian

Ach, teraz rozumiem, dokąd zmierzasz - więc jeśli tworzę projekt opakowujący, dołączam odniesienia za pomocą zwykłego „projektu klikniętego prawym przyciskiem myszy> Dodaj odniesienie”, wtedy mogę utworzyć nuspeczawierający wszystko w binkatalogu (zakładając, że moje odniesienia są „kopiuj lokalnie”), automatycznie przejmie wszystko, co dodałem. Wydaje się trochę skręcona, ale prawdopodobnie zadziała.
drzaus

6
Nie pobierze automatycznie wszystkiego, co jest w twoim katalogu bin, musisz to wyraźnie określić, coś takiego:<file src="bin\release\*.dll" target="lib" />
Julian

2
Warto zauważyć, że jeśli projekty, do których się odwołujemy, mają plik nuspec, wówczas nuget potraktuje go jako pakiet i NIE dołączy go do folderu lib, ale doda go do zależności pakietu
robkabyte

5

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>

7
Brzmi obiecująco, ale za mało informacji, aby je wdrożyć. Co to jest ten plik NuGet.targets, o którym mówisz? Znam ogólnie pliki docelowe budowania, ale nie ten konkretny przypadek użycia
bikeman868

2

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 ;).


1
Czy jest też rozwiązanie dla VS2017?
Dominic Jonas

Nie działa to w przypadku generowania pakietów na serwerze kompilacji.
Michi-2142

Szkoda, że ​​to jest przestarzałe. Byłoby przydatne.
joelc

2

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.

wprowadź opis obrazu tutaj

.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>

1
to od razu rozwiązało mój problem. Postępowałem zgodnie z instrukcją wymienioną w linku i zadziałało. Miło, że w odpowiedzi dodano również sedno.
Jabez
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.