Udostępnij za pośrednictwem

Tworzenie pakietu przy użyciu interfejsu wiersza polecenia nuget.exe

  • Artykuł

Bez względu na to, co pakiet robi lub jaki kod zawiera, należy użyć jednego z narzędzi interfejsu wiersza polecenia lub , aby spakować tę funkcjonalność do składnika, nuget.exe dotnet.exektóry może być udostępniany i używany przez dowolną liczbę innych deweloperów. Aby zainstalować narzędzia interfejsu wiersza polecenia NuGet, zobacz Instalowanie narzędzi klienckich NuGet. Należy pamiętać, że program Visual Studio nie zawiera automatycznie narzędzia interfejsu wiersza polecenia.

Technicznie rzecz biorąc, pakiet NuGet to tylko plik ZIP, którego nazwa została zmieniona z rozszerzeniem i którego zawartość jest zgodna z .nupkg niektórymi konwencjami. W tym temacie opisano szczegółowy proces tworzenia pakietu spełniającego te konwencje.

Pakowanie rozpoczyna się od skompilowanego kodu (zestawów), symboli i/lub innych plików, które mają być dostarczane jako pakiet (zobacz Przegląd i przepływ pracy). Ten proces jest niezależny od kompilowania lub generowania w inny sposób plików, które przechodzą do pakietu, chociaż można pobierać z informacji w pliku projektu w celu zachowania synchronizacji skompilowanych zestawów i pakietów.

Ważne

Ten temat dotyczy projektów innych niż zestaw SDK, zazwyczaj projektów innych niż projekty .NET Core i .NET Standard przy użyciu programu Visual Studio 2017 i nowszych wersji oraz pakietów NuGet 4.0 lub nowszych.

Wybieranie zestawów do spakowania

Większość pakietów ogólnego przeznaczenia zawiera co najmniej jeden zestaw, którego inni deweloperzy mogą używać we własnych projektach.

  • Ogólnie rzecz biorąc, najlepiej mieć jeden zestaw na pakiet NuGet, pod warunkiem, że każdy zestaw jest niezależnie przydatny. Jeśli na przykład masz element Utilities.dll zależny Parser.dllod elementu i Parser.dll jest on przydatny samodzielnie, utwórz jeden pakiet dla każdego z nich. Dzięki temu deweloperzy mogą używać Parser.dll niezależnie od Utilities.dllprogramu .

  • Jeśli biblioteka składa się z wielu zestawów, które nie są niezależnie przydatne, warto połączyć je w jeden pakiet. Korzystając z poprzedniego przykładu, jeśli Parser.dll zawiera kod, który jest używany tylko przez Utilities.dllprogram , wówczas należy zachować Parser.dll ten sam pakiet.

  • Podobnie, jeśli Utilities.dll zależy od Utilities.resources.dll, gdzie ponownie ten ostatni nie jest przydatny samodzielnie, umieść oba w tym samym pakiecie.

Zasoby są w rzeczywistości specjalnym przypadkiem. Po zainstalowaniu pakietu w projekcie nuGet automatycznie dodaje odwołania do zestawów do bibliotek DLL pakietu, z wyłączeniem tych, które są nazwane.resources.dll, ponieważ zakłada się, że mają być zlokalizowane zestawy satelitarne (zobacz Tworzenie zlokalizowanych pakietów). Z tego powodu należy unikać używania .resources.dll plików, które w przeciwnym razie zawierają podstawowy kod pakietu.

Jeśli biblioteka zawiera zestawy międzyoperackich modelu COM, postępuj zgodnie z dodatkowymi wytycznymi w temacie Tworzenie pakietów z zestawami międzyoperacowymi modelu COM.

Rola i struktura pliku nuspec

Gdy już wiesz, jakie pliki chcesz spakować, następnym krokiem jest utworzenie manifestu pakietu w .nuspec pliku XML.

Manifest:

  1. Opisuje zawartość pakietu i sam jest zawarty w pakiecie.
  2. Napędza zarówno tworzenie pakietu, jak i instruuje NuGet, jak zainstalować pakiet w projekcie. Na przykład manifest identyfikuje inne zależności pakietów, takie jak NuGet może również instalować te zależności po zainstalowaniu głównego pakietu.
  3. Zawiera zarówno wymagane, jak i opcjonalne właściwości, jak opisano poniżej. Aby uzyskać szczegółowe informacje, w tym inne właściwości, które nie zostały wymienione tutaj, zobacz dokumentację narzędzia .nuspec.

Wymagane właściwości:

  • Identyfikator pakietu, który musi być unikatowy w całej galerii, która hostuje pakiet.
  • Określony numer wersji w postaci Major.Minor.Patch[-Sufiks] gdzie -Sufiks identyfikuje wersje wstępne
  • Tytuł pakietu powinien być wyświetlany na hoście (na przykład nuget.org)
  • Informacje o tworzeniu i właścicielu.
  • Długi opis pakietu.

Typowe właściwości opcjonalne:

  • Informacje o wersji
  • Informacje o prawach autorskich
  • Krótki opis interfejsu użytkownika Menedżer pakietów w programie Visual Studio
  • Identyfikator ustawień regionalnych
  • Adres URL projektu
  • Licencja jako wyrażenie lub plik (licenseUrl jest przestarzała, zamiast tego użyj license elementu metadanych nuspec)
  • Plik ikony (iconUrl jest przestarzałym zamiast tego użyj icon elementu metadanych nuspec)
  • Listy zależności i odwołań
  • Tagi, które ułatwiają wyszukiwanie w galerii

Poniżej przedstawiono typowy (ale fikcyjny) .nuspec plik z komentarzami opisującym właściwości:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
    <metadata>
        <!-- Identifier that must be unique within the hosting gallery -->
        <id>Contoso.Utility.UsefulStuff</id>

        <!-- Package version number that is used when resolving dependencies -->
        <version>1.8.3</version>

        <!-- Authors contain text that appears directly on the gallery -->
        <authors>Dejana Tesic, Rajeev Dey</authors>

        <!-- 
            Owners are typically nuget.org identities that allow gallery
            users to easily find other packages by the same owners.  
        -->
        <owners>dejanatc, rjdey</owners>
        
         <!-- Project URL provides a link for the gallery -->
        <projectUrl>http://github.com/contoso/UsefulStuff</projectUrl>

         <!-- License information is displayed on the gallery -->
        <license type="expression">Apache-2.0</license>
        

        <!-- Icon is used in Visual Studio's package manager UI -->
        <icon>icon.png</icon>

        <!-- 
            If true, this value prompts the user to accept the license when
            installing the package. 
        -->
        <requireLicenseAcceptance>false</requireLicenseAcceptance>

        <!-- Any details about this particular release -->
        <releaseNotes>Bug fixes and performance improvements</releaseNotes>

        <!-- 
            The description can be used in package manager UI. Note that the
            nuget.org gallery uses information you add in the portal. 
        -->
        <description>Core utility functions for web applications</description>

        <!-- Copyright information -->
        <copyright>Copyright ©2016 Contoso Corporation</copyright>

        <!-- Tags appear in the gallery and can be used for tag searches -->
        <tags>web utility http json url parsing</tags>

        <!-- Dependencies are automatically installed when the package is installed -->
        <dependencies>
            <dependency id="Newtonsoft.Json" version="9.0" />
        </dependencies>
    </metadata>

    <!-- A readme.txt to display when the package is installed -->
    <files>
        <file src="readme.txt" target="" />
        <file src="icon.png" target="" />
    </files>
</package>

Aby uzyskać szczegółowe informacje na temat deklarowania zależności i określania numerów wersji, zobacz packages.config i Package versioning (Wersje pakietów). Istnieje również możliwość uwidocznego stosowania zasobów z zależności bezpośrednio w pakiecie przy użyciu include atrybutów i exclude dla dependency elementu . Zobacz .nuspec Reference - Dependencies (Dokumentacja narzędzia .nuspec — zależności).

Ponieważ manifest jest zawarty w pakiecie utworzonym na jego podstawie, możesz znaleźć dowolną liczbę dodatkowych przykładów, sprawdzając istniejące pakiety. Dobrym źródłem jest folder global-packages na komputerze, którego lokalizacja jest zwracana przez następujące polecenie:

nuget locals -list global-packages

Przejdź do dowolnego folderu package\version , skopiuj .nupkg plik do .zip pliku, a następnie otwórz .zip ten plik i sprawdź .nuspec w nim.

Uwaga

Podczas tworzenia elementu .nuspec z projektu programu Visual Studio manifest zawiera tokeny, które są zastępowane informacjami z projektu podczas kompilowania pakietu. Zobacz Tworzenie pliku nuspec z projektu programu Visual Studio.

Tworzenie pliku nuspec

Tworzenie kompletnego manifestu zwykle rozpoczyna się od pliku podstawowego .nuspec wygenerowanego za pomocą jednej z następujących metod:

Następnie edytujesz plik ręcznie, aby opisano dokładną zawartość, którą chcesz uzyskać w końcowym pakiecie.

Ważne

.nuspec Wygenerowane pliki zawierają symbole zastępcze, które należy zmodyfikować przed utworzeniem pakietu za nuget pack pomocą polecenia . To polecenie kończy się niepowodzeniem, jeśli .nuspec element zawiera symbole zastępcze.

Z katalogu roboczego opartego na konwencji

Ponieważ pakiet NuGet to tylko plik ZIP, którego nazwa została zmieniona przy .nupkg użyciu rozszerzenia, często najłatwiej jest utworzyć strukturę folderów w lokalnym systemie plików, a następnie utworzyć .nuspec plik bezpośrednio z tej struktury. Następnie nuget pack polecenie automatycznie dodaje wszystkie pliki w tej strukturze folderów (z wyłączeniem wszystkich folderów rozpoczynających się od ., co pozwala zachować pliki prywatne w tej samej strukturze).

Zaletą tego podejścia jest to, że nie trzeba określać w manifeście, które pliki mają zostać uwzględnione w pakiecie (jak wyjaśniono w dalszej części tego tematu). Proces kompilacji może po prostu utworzyć dokładną strukturę folderów, która przechodzi do pakietu, i można łatwo dołączyć inne pliki, które mogą nie być częścią projektu w przeciwnym razie:

  • Zawartość i kod źródłowy, który powinien zostać wstrzyknięty do projektu docelowego.
  • Skrypty programu PowerShell
  • Przekształcenia do istniejących plików konfiguracji i kodu źródłowego w projekcie.

Konwencje folderów są następujące:

Folder opis Akcja po zainstalowaniu pakietu
(katalog główny) Lokalizacja readme.txt Program Visual Studio wyświetla plik readme.txt w katalogu głównym pakietu po zainstalowaniu pakietu.
lib/{tfm} Pliki zestawów (), dokumentacji (.dll.xml) i symboli (.pdb) dla danej platformy docelowej Moniker (TFM) Zestawy są dodawane jako odwołania do kompilowania, a także środowiska uruchomieniowego; .xml i .pdb skopiowane do folderów projektu. Zobacz Obsługa wielu platform docelowych na potrzeby tworzenia podfolderów specyficznych dla platformy.
ref/{tfm} Pliki zestawów (.dll) i symboli (.pdb) dla danej struktury docelowej Moniker (TFM) Zestawy są dodawane jako odwołania tylko dla czasu kompilacji; Dlatego nic nie zostanie skopiowane do folderu bin projektu.
środowiska uruchomieniowe Zestaw specyficzny dla architektury (), symbol (.dll.pdb) i pliki zasobów natywnych (.pri) Zestawy są dodawane jako odwołania tylko dla środowiska uruchomieniowego; inne pliki są kopiowane do folderów projektu. Zawsze w folderze powinien istnieć odpowiedni zestaw /ref/{tfm} specyficzny dla programu (TFM), AnyCPU aby zapewnić odpowiedni zestaw czasu kompilacji. Zobacz Obsługa wielu platform docelowych.
content Dowolne pliki Zawartość jest kopiowana do katalogu głównego projektu. Folder zawartości należy traktować jako katalog główny aplikacji docelowej, która ostatecznie korzysta z pakietu. Aby pakiet mógł dodać obraz w folderze /images aplikacji, umieść go w folderze content/images pakietu.
build (3.x+) MSBuild .targets i .props pliki Automatycznie wstawione do projektu.
buildMultiTargeting (4.0+) Program MSBuild .targets i .props pliki przeznaczone dla wielu platform docelowych Automatycznie wstawione do projektu.
buildTransitive (5.0+) MsBuild .targets i .props pliki, które przepływają przechodnio do dowolnego projektu zużywanego. Zobacz stronę funkcji. Automatycznie wstawione do projektu.
tools Skrypty i programy programu PowerShell dostępne z poziomu konsoli Menedżer pakietów Folder tools jest dodawany do zmiennej środowiskowej PATH tylko dla konsoli Menedżer pakietów (w szczególności nie jako PATH ustawiony dla programu MSBuild podczas kompilowania projektu).

Ponieważ struktura folderów może zawierać dowolną liczbę zestawów dla dowolnej liczby platform docelowych, ta metoda jest niezbędna podczas tworzenia pakietów obsługujących wiele struktur.

W każdym razie po utworzeniu żądanej struktury folderów uruchom następujące polecenie w tym folderze, aby utworzyć .nuspec plik:

nuget spec

Ponownie wygenerowany .nuspec element nie zawiera jawnych odwołań do plików w strukturze folderów. Narzędzie NuGet automatycznie dołącza wszystkie pliki po utworzeniu pakietu. Nadal trzeba jednak edytować wartości symboli zastępczych w innych częściach manifestu.

Z biblioteki DLL zestawu

W prostym przypadku tworzenia pakietu na podstawie zestawu można wygenerować .nuspec plik z metadanych w zestawie przy użyciu następującego polecenia:

nuget spec <assembly-name>.dll

Użycie tego formularza zastępuje kilka symboli zastępczych w manifeście określonymi wartościami z zestawu. Na przykład <id> właściwość jest ustawiona na nazwę zestawu i <version> jest ustawiona na wersję zestawu. Inne właściwości w manifeście nie mają jednak pasujących wartości w zestawie i w związku z tym nadal zawierają symbole zastępcze.

Z projektu programu Visual Studio

Tworzenie elementu .nuspec z pliku .csproj lub .vbproj jest wygodne, ponieważ inne pakiety zainstalowane w tym projekcie są automatycznie przywoływane jako zależności. Wystarczy użyć następującego polecenia w tym samym folderze co plik projektu:

# Use in a folder containing a project file <project-name>.csproj or <project-name>.vbproj
nuget spec

Wynikowy <project-name>.nuspec plik zawiera tokeny , które są zastępowane w czasie pakowania wartościami z projektu, w tym odwołaniami do innych pakietów, które zostały już zainstalowane.

Jeśli masz zależności pakietów do uwzględnienia w pliku nuspec, zamiast tego użyj polecenia nuget packi pobierz plik nuspec z wygenerowanego pliku nupkg . Na przykład użyj następującego polecenia.

# Use in a folder containing a project file <project-name>.csproj or <project-name>.vbproj
nuget pack myproject.csproj

Token jest rozdzielany symbolami $ po obu stronach właściwości projektu. Na przykład <id> wartość w manifeście wygenerowana w ten sposób zwykle jest wyświetlana w następujący sposób:

<id>$id$</id>

Ten token jest zastępowany wartością AssemblyName pliku projektu w czasie pakowania. Aby uzyskać dokładne mapowanie wartości projektu na .nuspec tokeny, zobacz dokumentację tokenów zastępczych.

Tokeny zwalniają z konieczności aktualizowania kluczowych wartości, takich jak numer wersji w programie podczas .nuspec aktualizowania projektu. (Zawsze można zastąpić tokeny wartościami literału, jeśli jest to konieczne).

Pamiętaj, że podczas pracy z projektem programu Visual Studio dostępnych jest kilka dodatkowych opcji tworzenia pakietów, zgodnie z opisem w temacie Uruchamianie pakietu nuget w celu późniejszego wygenerowania pliku nupkg.

Pakiety na poziomie rozwiązania

Tylko nuGet 2.x. Niedostępne w programie NuGet 3.0 lub nowszym.

Program NuGet 2.x obsługiwał pojęcie pakietu na poziomie rozwiązania, który instaluje narzędzia lub dodatkowe polecenia dla konsoli Menedżer pakietów (zawartość tools folderu), ale nie dodaje odwołań, zawartości ani dostosowań kompilacji do dowolnych projektów w rozwiązaniu. Takie pakiety nie zawierają żadnych plików w swoich bezpośrednich libfolderach , contentlub build , a żadna z jego zależności nie zawiera plików w odpowiednich libfolderach , contentlub build .

Program NuGet śledzi zainstalowane pakiety na poziomie rozwiązania w packages.config pliku w .nuget folderze, a nie w pliku projektu packages.config .

Nowy plik z wartościami domyślnymi

Następujące polecenie tworzy domyślny manifest z symbolami zastępczymi, co gwarantuje rozpoczęcie od odpowiedniej struktury plików:

nuget spec [<package-name>]

Jeśli pominięto <nazwę> pakietu, wynikowy plik to Package.nuspec. Jeśli podasz nazwę, taką jak Contoso.Utility.UsefulStuff, plik to Contoso.Utility.UsefulStuff.nuspec.

.nuspec Wynikowy zawiera symbole zastępcze dla wartości, takich jak projectUrl. Pamiętaj, aby edytować plik przed jego użyciem w celu utworzenia pliku końcowego .nupkg .

Wybierz unikatowy identyfikator pakietu i ustawienie numeru wersji

Identyfikator pakietu (<id> element) i numer wersji (<version> element) to dwie najważniejsze wartości w manifeście, ponieważ jednoznacznie identyfikują dokładny kod zawarty w pakiecie.

Najlepsze rozwiązania dotyczące identyfikatora pakietu:

  • Unikatowość: identyfikator musi być unikatowy w nuget.org lub w dowolnej galerii hostuje pakiet. Przed podjęciem decyzji o identyfikatorze wyszukaj odpowiednią galerię, aby sprawdzić, czy nazwa jest już używana. Aby uniknąć konfliktów, dobrym wzorcem jest użycie nazwy firmy jako pierwszej części identyfikatora, takiej jak Contoso..
  • Nazwy podobne do przestrzeni nazw: postępuj zgodnie ze wzorcem podobnym do przestrzeni nazw na platformie .NET, używając notacji kropkowej zamiast łączników. Na przykład użyj polecenia Contoso.Utility.UsefulStuff , a nie Contoso-Utility-UsefulStuff lub Contoso_Utility_UsefulStuff. Konsumenci uważają również, że jest to przydatne, gdy identyfikator pakietu jest zgodny z przestrzeniami nazw używanymi w kodzie.
  • Przykładowe pakiety: jeśli utworzysz pakiet przykładowego kodu, który pokazuje, jak używać innego pakietu, dołącz .Sample jako sufiks do identyfikatora, jak w Contoso.Utility.UsefulStuff.Samplepliku . (Przykładowy pakiet będzie oczywiście mieć zależność od innego pakietu). Podczas tworzenia przykładowego pakietu użyj metody katalogów roboczych opartej na konwencji opisanej wcześniej. W folderze content umieść przykładowy kod w folderze o nazwie \Samples\<identifier> w formacie \Samples\Contoso.Utility.UsefulStuff.Sample.

Najlepsze rozwiązania dotyczące wersji pakietu:

  • Ogólnie rzecz biorąc, ustaw wersję pakietu tak, aby odpowiadała bibliotece, chociaż nie jest to ściśle wymagane. Jest to prosta kwestia, gdy ograniczasz pakiet do pojedynczego zestawu, zgodnie z opisem we wcześniejszej sekcji Wybieranie zestawów do pakietu. Ogólnie rzecz biorąc, należy pamiętać, że sam pakiet NuGet obsługuje wersje pakietów podczas rozpoznawania zależności, a nie wersji zestawów.
  • W przypadku korzystania ze standardowego schematu wersji należy wziąć pod uwagę reguły przechowywania wersji NuGet, jak wyjaśniono w artykule Przechowywanie wersji pakietów.

Poniższa seria krótkich wpisów w blogu jest również przydatna do zrozumienia przechowywania wersji:

Dodawanie pliku readme i innych plików

Aby bezpośrednio określić pliki do uwzględnienia w pakiecie, użyj węzła w .nuspec pliku, który jest zgodny z tagiem<metadata>:<files>

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
    <metadata>
    <!-- ... -->
    </metadata>
    <files>
        <!-- Add a readme -->
        <file src="readme.txt" target="" />

        <!-- Add files from an arbitrary folder that's not necessarily in the project -->
        <file src="..\..\SomeRoot\**\*.*" target="" />
    </files>
</package>

Napiwek

W przypadku korzystania z podejścia do katalogu roboczego opartego na konwencji można umieścić readme.txt w katalogu głównym pakietu i innej zawartości w folderze content . W manifeście nie są wymagane żadne <file> elementy.

Po dołączeniu pliku o nazwie readme.txt w katalogu głównym pakietu program Visual Studio wyświetla zawartość tego pliku jako zwykły tekst bezpośrednio po zainstalowaniu pakietu. (Pliki Readme nie są wyświetlane dla pakietów zainstalowanych jako zależności). Na przykład poniżej przedstawiono sposób wyświetlania pliku readme pakietu HtmlAgilityPack:

The display of a readme file for a NuGet package upon installation

Uwaga

Jeśli do pliku dołączysz pusty <files> węzeł .nuspec , pakiet NuGet nie zawiera żadnej innej zawartości w pakiecie innym niż zawartość w folderze lib .

Uwzględnij rekwizyty i elementy docelowe programu MSBuild w pakiecie

W niektórych przypadkach możesz dodać niestandardowe obiekty docelowe kompilacji lub właściwości w projektach korzystających z pakietu, takich jak uruchamianie niestandardowego narzędzia lub procesu podczas kompilacji. Więcej informacji o rekwizytach i elementach docelowych programu MSBuild można dowiedzieć się w pakietach NuGet

Utwórz <package_id>.targets lub <package_id>.props (na przykład Contoso.Utility.UsefulStuff.targets) w folderach kompilacji projektu.

Następnie w .nuspec pliku pamiętaj, aby odwołać się do tych plików w węźle <files> :

<?xml version="1.0"?>
<package >
    <metadata minClientVersion="2.5">
    <!-- ... -->
    </metadata>
    <files>
        <!-- Include everything in \build -->
        <file src="build\**" target="build" />

        <!-- Other files -->
        <!-- ... -->
    </files>
</package>

Po dodaniu pakietów do projektu program NuGet automatycznie uwzględni te rekwizyty i obiekty docelowe.

Uruchom pakiet nuget, aby wygenerować plik nupkg

W przypadku korzystania z zestawu lub katalogu roboczego opartego na konwencji utwórz pakiet, uruchamiając nuget pack plik .nuspec , zastępując <project-name> element określonym nazwą pliku:

nuget pack <project-name>.nuspec

W przypadku korzystania z projektu programu Visual Studio uruchom nuget pack polecenie z plikiem projektu, który automatycznie ładuje plik projektu .nuspec i zastępuje wszystkie tokeny w nim przy użyciu wartości w pliku projektu:

nuget pack <project-name>.csproj

Uwaga

Użycie pliku projektu bezpośrednio jest niezbędne do zastąpienia tokenu, ponieważ projekt jest źródłem wartości tokenu. Zamiana tokenu nie występuje w przypadku użycia nuget pack z plikiem .nuspec .

We wszystkich przypadkach wyklucza foldery rozpoczynające nuget pack się od okresu, takiego jak .git lub .hg.

NuGet wskazuje, czy w .nuspec pliku występują błędy, które wymagają poprawienia, takie jak zapominanie o zmianie wartości symboli zastępczych w manifeście.

Po nuget pack pomyślnym zakończeniu będziesz mieć .nupkg plik, który można opublikować w odpowiedniej galerii zgodnie z opisem w temacie Publikowanie pakietu.

Napiwek

Przydatnym sposobem sprawdzenia pakietu po jego utworzeniu jest otwarcie go w narzędziu Eksplorator pakietów. Zapewnia to graficzny widok zawartości pakietu i jego manifestu. Możesz również zmienić nazwę wynikowego .nupkg .zip pliku na plik i bezpośrednio eksplorować jego zawartość.

Opcje dodatkowe

Za pomocą różnych przełączników nuget pack wiersza polecenia można wykluczyć pliki, zastąpić numer wersji w manifeście i zmienić folder wyjściowy, między innymi. Aby uzyskać pełną listę, zapoznaj się z dokumentacją poleceń pakietu.

Poniżej przedstawiono kilka opcji, które są typowe dla projektów programu Visual Studio:

  • Przywołyzowane projekty: jeśli projekt odwołuje się do innych projektów, możesz dodać przywołyne projekty w ramach pakietu lub jako zależności, używając -IncludeReferencedProjects opcji:

    nuget pack MyProject.csproj -IncludeReferencedProjects

    Ten proces dołączania jest cyklicznych, więc jeśli MyProject.csproj odwołania do projektów B i C, a te projekty odwołują się do D, E i F, pliki z B, C, D, E i F są uwzględnione w pakiecie.

    Jeśli przywoływał projekt zawiera .nuspec własny plik, zamiast tego nuGet dodaje ten projekt, do którego odwołuje się zależność. Musisz spakować i opublikować ten projekt oddzielnie.

  • Konfiguracja kompilacji: Domyślnie pakiet NuGet używa domyślnego zestawu konfiguracji kompilacji w pliku projektu, zazwyczaj Debuguj. Aby spakować pliki z innej konfiguracji kompilacji, takiej jak Release, użyj -properties opcji z konfiguracją:

    nuget pack MyProject.csproj -properties Configuration=Release

  • Symbole: aby uwzględnić symbole, które umożliwiają konsumentom przechodzenie przez kod pakietu w debugerze, użyj -Symbols opcji:

    nuget pack MyProject.csproj -symbols

Instalacja pakietu testowego

Przed opublikowaniem pakietu zazwyczaj chcesz przetestować proces instalowania pakietu w projekcie. Testy zapewniają, że wszystkie pliki muszą być przechowywane w odpowiednich miejscach w projekcie.

Instalacje można testować ręcznie w programie Visual Studio lub w wierszu polecenia przy użyciu zwykłych kroków instalacji pakietu.

W przypadku testowania automatycznego podstawowy proces jest następujący:

  1. .nupkg Skopiuj plik do folderu lokalnego.
  2. Dodaj folder do źródeł pakietów przy użyciu nuget sources add -name <name> -source <path> polecenia (zobacz źródła nuget). Należy pamiętać, że należy ustawić to źródło lokalne tylko raz na dowolnym komputerze.
  3. Zainstaluj pakiet z tego źródła przy użyciu polecenia nuget install <packageID> -source <name> , gdzie <name> odpowiada nazwie źródła jako podanej .nuget sources Określenie źródła gwarantuje, że pakiet jest zainstalowany tylko z tego źródła.
  4. Sprawdź system plików, aby sprawdzić, czy pliki są poprawnie zainstalowane.

Następne kroki

Po utworzeniu pakietu, który jest plikiem .nupkg , możesz opublikować go w wybranej galerii zgodnie z opisem w temacie Publikowanie pakietu.

Możesz również rozszerzyć możliwości pakietu lub w inny sposób obsługiwać inne scenariusze, zgodnie z opisem w następujących tematach:

Na koniec istnieją dodatkowe typy pakietów, o których należy pamiętać: