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

Niezależnie od tego, co pakiet robi lub jaki kod zawiera, należy użyć jednego z narzędzi interfejsu wiersza polecenia (CLI) lub , aby spakować tę funkcjonalność do składnika, nuget.exedotnet.exektóry może być udostępniany i używany przez innych deweloperów. Aby zainstalować narzędzia interfejsu wiersza polecenia NuGet, zobacz Instalowanie narzędzi klienckich NuGet. Visual Studio nie zawiera automatycznie narzędzia interfejsu wiersza polecenia.

• W przypadku projektów w stylu innym niż SDK, zazwyczaj projektów .NET Framework, wykonaj kroki opisane w tym artykule, aby utworzyć pakiet. Aby zapoznać się z przewodnikiem Szybki start zawierającym instrukcje krok po kroku dotyczące używania Visual Studio i interfejsu wiersza polecenia nuget.exe, zobacz Quickstart: tworzenie i publikowanie pakietu przy użyciu platformy Visual Studio (.NET Framework, Windows).

• W przypadku projektów .NET Core i .NET Standard korzystających z formatu w stylu SDK i innych projektów w stylu zestawu SDK zobacz Utwórz pakiet NuGet przy użyciu interfejsu wiersza polecenia dotnet.

• W przypadku projektów migrowanych z packages.config do PackageReference, użyj polecenia msbuild -t:pack.

Technicznie pakiet NuGet jest plikiem ZIP, którego nazwa została zmieniona, aby mieć rozszerzenie .nupkg i którego zawartość jest zgodna z niektórymi konwencjami. W tym artykule opisano szczegółowy proces tworzenia pakietu spełniającego te konwencje.

Pakowanie rozpoczyna się od skompilowanego kodu (zestawów), symboli i innych plików, które mają być dostarczane jako pakiet. Aby zapoznać się z omówieniem procesu tworzenia pakietów, zobacz Przepływ pracy tworzenia pakietów. Ten proces jest niezależny od kompilowania lub generowania plików, które przechodzą do pakietu. Można jednak pobierać informacje z pliku projektu, aby zachować synchronizację skompilowanych zestawów i pakietów.

Zadecyduj, które zestawy spakować

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. Rozważmy na przykład następujące przypadki, które obejmują zestaw o nazwie Utilities.dll , który zależy od zestawu o nazwie Parser.dll:

• Jeśli Parser.dll jest przydatna samodzielnie, utwórz jeden pakiet dla Utilities.dll i jeden dla Parser.dll. Dzięki temu deweloperzy mogą używać Parser.dll niezależnie od Utilities.dll.

• Jeśli Parser.dll zawiera kod używany tylko przez Utilities.dll, należy zachować Parser.dll w tym samym pakiecie. Ogólnie rzecz biorąc, jeśli biblioteka składa się z wielu zestawów, które nie są niezależnie przydatne, warto połączyć je w jeden pakiet.

• Jeśli Utilities.dll również zależy od Utilities.resources.dll, a Utilities.resources.dll nie jest przydatna samodzielnie, umieść oba te elementy w tym samym pakiecie.

Zasoby, takie jak zestaw Utilities.resources.dll w poprzednim przykładzie, są szczególnym przypadkiem. Po zainstalowaniu pakietu w projekcie NuGet automatycznie dodaje referencje do zestawów do bibliotek DLL pakietu, z wyłączeniem tych, które mają nazwę .resources.dll, ponieważ są uznawane za zlokalizowane zestawy satelitarne. Aby uzyskać więcej informacji na temat zlokalizowanych wersji biblioteki, zobacz Tworzenie zlokalizowanych pakietów NuGet. Z tego powodu należy unikać używania .resources.dll plików zawierających podstawowy kod pakietu.

Jeśli Twoja biblioteka zawiera zestawy międzyoperacyjne modelu obiektów komponentów (COM), postępuj zgodnie z dodatkowymi wytycznymi w temacie Tworzenie pakietów NuGet zawierających zestawy międzyoperacyjne modelu COM.

Rola i struktura pliku .nuspec

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

Manifest:

• Opisuje zawartość pakietu i sam jest zawarty w pakiecie.
• Napędza tworzenie pakietu i informuje NuGet, jak zainstalować pakiet w projekcie. Na przykład manifest identyfikuje inne zależności pakietów, aby program NuGet mógł również zainstalować te zależności po zainstalowaniu głównego pakietu.
• Zawiera zarówno wymagane, jak i opcjonalne właściwości zgodnie z opisem w pozostałej części tej sekcji. Aby uzyskać szczegółowe informacje, w tym inne właściwości, o których nie wspomniano tutaj, zobacz .nuspec reference (Dokumentacja narzędzia .nuspec).

Następujące właściwości są wymagane w manifeście:

• 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, jak powinien być przedstawiony na hoście (na przykład nuget.org)
• Informacje o autorze
• Długi opis pakietu

Poniżej przedstawiono typowe właściwości opcjonalne:

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

Poniższy kod to typowy (ale fikcyjny) plik nuspec z komentarzami opisujący właściwości:

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

        <!-- A package version number that's used when resolving dependencies -->
        <version>1.8.3</version>

        <!-- A comma-separated list of package authors that sometimes appears directly on the gallery -->
        <authors>Dejana Tesic, Rajeev Dey</authors>

        <!-- A project URL that provides a link for the gallery -->
        <projectUrl>http://github.com/contoso/UsefulStuff</projectUrl>

        <!-- License information that's displayed on the gallery -->
        <license type="expression">Apache-2.0</license>
        
        <!-- The location of a read-me file that's displayed in the Visual Studio Package Manager UI -->
        <readme>readme.md</readme>

        <!-- An icon that's used in the Visual Studio Package Manager UI -->
        <icon>icon.png</icon>

        <!-- 
            A property that when true, prompts the user to accept the license when
            installing the package
        -->
        <requireLicenseAcceptance>false</requireLicenseAcceptance>

        <!-- Detailed information about a particular release -->
        <releaseNotes>Bug fixes and performance improvements</releaseNotes>

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

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

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

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

    <!-- A read-me Markdown file that's displayed in the Package Manager UI -->
    <files>
        <file src="readme.md" 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 Przechowywanie wersji pakietu. Można również użyć atrybutów include i exclude w elemencie dependency, aby określić zasoby zależności, które chcesz dołączyć lub wykluczyć z pakietu. Aby uzyskać więcej informacji, zobacz .nuspec Reference - Dependencies, element.

Ponieważ manifest jest zawarty w pakiecie utworzonym na jego podstawie, możesz znaleźć przykłady, sprawdzając istniejące pakiety. Dobrym źródłem jest folder global-packages na komputerze. Aby znaleźć jego lokalizację, użyj następującego polecenia:

nuget locals -list global-packages

Po zapoznaniu się z lokalizacją folderu global-packages wykonaj następujące kroki, aby znaleźć plik manifestu:

1. Przejdź do folderu global-packages .
2. W tym folderze przejdź do podfolderu dla dowolnego pakietu, a następnie przejdź do podfolderu dla dowolnej wersji tego pakietu.
3. W podfolderze wersji utwórz kopię pliku nupkg i zmień rozszerzenie kopii na zip.
4. Otwórz plik .zip i sprawdź w nim plik nuspec .

Utwórz plik .nuspec

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

• Katalog roboczy oparty na konwencji
• Biblioteka DLL zestawu
• projekt Visual Studio
• Nowy plik z wartościami domyślnymi

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

Z katalogu roboczego opartego na konwencji

Ponieważ pakiet NuGet jest plikiem ZIP, którego nazwa została zmieniona przy użyciu rozszerzenia nupkg , często najłatwiej jest utworzyć strukturę folderów, którą chcesz utworzyć w lokalnym systemie plików, a następnie utworzyć plik nuspec bezpośrednio z tej struktury. Następnie polecenie nuget pack automatycznie dodaje wszystkie pliki w tej strukturze folderów, ale wyklucza wszelkie foldery, które rozpoczynają się od kropki, umożliwiając utrzymanie prywatnych plików 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 tej sekcji. Zamiast tego proces kompilacji może utworzyć dokładną strukturę folderów, która przechodzi do pakietu. Możesz również ł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 istniejących plików konfiguracji i kodu źródłowego w projekcie

Foldery są zgodne z następującymi konwencjami:

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

Jeśli masz odpowiednią strukturę folderów, uruchom następujące polecenie w tym folderze, aby utworzyć plik nuspec :

nuget spec

Wygenerowany plik nuspec 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 zestawu biblioteki DLL

W podstawowym przypadku tworzenia pakietu na podstawie zestawu można wygenerować plik nuspec 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 konkretnymi wartościami z modułu. 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. Te właściwości nadal zawierają symbole zastępcze po uruchomieniu polecenia.

Z projektu Visual Studio

Tworzenie pliku nuspec z pliku csproj lub vbproj jest wygodne, ponieważ inne pakiety zainstalowane w projekcie są automatycznie przywoływane jako zależności. Aby utworzyć manifest na podstawie pliku projektu, użyj następującego polecenia w folderze zawierającym plik projektu:

# Use in a folder that contains a project file, such as <project-name>.csproj or <project-name>.vbproj.
nuget spec

Wynikowy <plik project-name.nuspec> 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 pack. Następnie pobierz plik nuspec z wygenerowanego pliku nupkg . Na przykład użyj następującego polecenia:

# Use in a folder that contains a project file, such as <project-name>.csproj or <project-name>.vbproj.
nuget pack myproject.csproj

Token jest ograniczony symbolami $ po obu stronach właściwości projektu. Na przykład wartość <id> w manifeście wygenerowanym w ten sposób zwykle wygląda następująco:

<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 tokeny pliku .nuspec, zobacz Tokeny zastępcze.

Tokeny zwalniają z konieczności aktualizowania kluczowych wartości, takich jak numer wersji w pliku nuspec podczas aktualizowania projektu. Można jednak również zastąpić tokeny literałami.

Kilka dodatkowych opcji tworzenia pakietów jest dostępnych podczas pracy nad projektem Visual Studio, zgodnie z opisem w Uruchom nuget pack w celu wygenerowania pliku .nupkg w dalszej części tego artykułu.

Pakiety na poziomie rozwiązania

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

Pakiet NuGet 2.x obsługuje koncepcję pakietu na poziomie rozwiązania, który instaluje narzędzia lub dodatkowe polecenia dla konsoli Menedżera Pakietów (zawartość folderu tools), ale nie dodaje odwołań, zawartości ani dostosowań kompilacji do projektów w rozwiązaniu. Takie pakiety nie zawierają żadnych plików w ich bezpośredniej bibliotece,zawartości lub folderach kompilacji , a żadna z ich zależności nie zawiera plików w odpowiednich folderach lib, zawartości lub kompilacji .

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

Z nowego pliku z wartościami domyślnymi

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

nuget spec [<package-name>]

Jeśli pominięto <package-name>plik wynikowy o nazwie Package.nuspec. Jeśli podasz nazwę, taką jak Contoso.Utility.UsefulStuff, plik ma nazwę Contoso.Utility.UsefulStuff.nuspec.

Wynikowy plik nuspec zawiera symbole zastępcze dla wartości, takich jak projectUrl. Przed użyciem pliku do utworzenia końcowego pliku nupkg zastąp symbole zastępcze odpowiednimi wartościami.

Wybierz unikatowy identyfikator pakietu i ustaw numer 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 galerii, która hostuje pakiet, na przykład nuget.org. 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 przypominające namespaces: Postępuj zgodnie ze wzorcem podobnym do przestrzeni nazw w .NET, używając notacji kropkowej zamiast łączników. Na przykład użyj Contoso.Utility.UsefulStuff zamiast 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 tworzysz 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 tego typu ma zależność od pakietu, który demonstruje sposób użycia. Podczas tworzenia przykładowego pakietu użyj metody katalogu roboczego opartej na konwencji opisanej wcześniej. W folderze zawartości umieść przykładowy kod w folderze o nazwie \Samples\<identifier>, tak jak w folderze \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. Te wskazówki są zalecane, ale nie są ściśle wymagane. Ta praktyka jest prosta w przypadku ograniczenia pakietu do pojedynczego zestawu, zgodnie z opisem we wcześniejszej sekcji Wybieranie zestawów do spakowania. 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 z niestandardowego schematu wersji należy wziąć pod uwagę zasady wersjonowania NuGet, jak wyjaśniono w artykule Wersjonowanie pakietów.

Aby zapoznać się z innymi zasobami pomocnymi w zrozumieniu wersji, zobacz następującą serię krótkich wpisów w blogu:

• Część 1: Walka z piekłem DLL
• Część 2. Algorytm podstawowy
• Część 3. Zjednoczenie za pośrednictwem przekierowań powiązań

Dodawanie pliku read-me i innych plików

Aby bezpośrednio określić pliki do uwzględnienia w pakiecie, użyj węzła <files> w pliku nuspec, który następuje po tagu <metadata>.

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
    <metadata>
        <!-- ... -->
    </metadata>
    <files>
        <!-- Add files from an arbitrary folder that's not necessarily in the project. -->
        <file src="..\..\SomeRoot\**\*.*" target="" />
    </files>
</package>

Aby dołączyć plik read-me do pakietu, użyj readme elementu metadata, aby określić ścieżkę docelową do pliku read-me. Użyj również elementu metadanych, aby określić ścieżkę źródłową file i folder docelowy pliku read-me. Aby uzyskać więcej informacji, zobacz readme.

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
    <metadata>
        <!-- ... -->
        <readme>docs\readme.md</readme>
        <!-- ... -->
    </metadata>
    <files>
        <!-- Add a read-me file. -->
        <file src="..\readme.md" target="docs\" />
    </files>
</package>

Visual Studio wyświetla zawartość pliku read-me w interfejsie użytkownika Menedżer pakietów. Na przykład poniższy zrzut ekranu przedstawia plik read-me dla HtmlAgilityPack pakietu:

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 do projektów korzystających z pakietu, takich jak uruchamianie niestandardowego narzędzia lub procesu podczas kompilacji. Aby uzyskać więcej informacji na temat niestandardowych obiektów docelowych i właściwości kompilacji, zobacz MSBuild .props i .targets w pakiecie.

Utwórz pliki package-id.targets lub package-id.props, takie jak Contoso.Utility.UsefulStuff.targets, w folderach build projektu.

Następnie w pliku nuspec odwołaj się do tych plików w węźle <files> :

<?xml version="1.0"?>
<package >
    <metadata minClientVersion="2.5">
    <!-- ... -->
    </metadata>
    <files>
        <!-- In the package build folder, include everything that's in the local build folder. -->
        <file src="build\**" target="build" />

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

Po dodaniu pakietów do projektu pakiet NuGet automatycznie uwzględnia te właściwości i obiekty docelowe.

Uruchom pakiet nuget, aby wygenerować plik nupkg

Jeśli używasz zestawu lub katalogu roboczego opartego na konwencji, utwórz pakiet, uruchamiając polecenie nuget pack z plikiem .nuspec. W poniższym poleceniu zastąp <project-name> nazwą swojego projektu:

nuget pack <project-name>.nuspec

Podczas korzystania z projektu Visual Studio uruchom nuget pack wraz z plikiem projektu. To polecenie automatycznie ładuje plik nuspec projektu i zastępuje wszystkie tokeny w nim odpowiednimi wartościami w pliku projektu:

nuget pack <project-name>.csproj

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

NuGet wskazuje, czy w pliku nuspec występują błędy wymagające poprawienia, takie jak wartości symboli zastępczych w manifeście, które należy zaktualizować.

Po nuget pack pomyślnym zakończeniu będziesz mieć plik .nupkg, który można opublikować w odpowiedniej galerii, jak opisano w rozdziale Publikowanie pakietów NuGet.

Dodatkowe opcje

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ę, zobacz pack command (NuGet CLI).

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

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

  nuget pack MyProject.csproj -IncludeReferencedProjects
  

  Ten proces dołączania jest rekursywny. Na przykład jeśli plik MyProject.csproj odwołuje się do projektów B i C, a te projekty odwołują się do D, E i F, pliki z plików B, C, D, E i F znajdują się w pakiecie.

  Jeśli przywoływany projekt zawiera własny plik .nuspec, NuGet dodaje ten projekt jako zależność. Musisz spakować i opublikować ten projekt oddzielnie.

• Konfiguracja kompilacji: Domyślnie pakiet NuGet używa domyślnej konfiguracji kompilacji ustawionej w pliku projektu, zazwyczaj Debug. 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 umożliwiające konsumentom przechodzenie przez kod pakietu w debugerze, użyj opcji -Symbols i -SymbolPackageFormat. W przypadku -SymbolPackageFormat opcji określ format snupkg:

  nuget pack MyProject.csproj -symbols -SymbolPackageFormat snupkg
  

Instalacja pakietu testowego

Przed opublikowaniem pakietu zazwyczaj chcesz przetestować proces instalowania pakietu w projekcie. Test pomaga upewnić się, że wszystkie niezbędne pliki są w prawidłowym miejscu w projekcie.

Instalacje można testować ręcznie w Visual Studio lub w wierszu polecenia przy użyciu standardowych kroków instalacji pakieć.

W przypadku testowania automatycznego można użyć następującego podstawowego procesu:

1. Skopiuj plik nupkg do folderu lokalnego.
2. Dodaj folder do źródeł pakietów przy użyciu nuget sources add -name <name> -source <path> polecenia . Aby uzyskać więcej informacji, zobacz polecenie źródła (interfejs wiersza polecenia NuGet). 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 <package-ID> -source <name>. W tym poleceniu <name> powinno być zgodne z nazwą źródła używanego w poleceniu nuget sources . Określenie źródła informuje nuGet o zainstalowaniu pakietu tylko z tego źródła.
4. Sprawdź system plików, aby sprawdzić, czy pliki są poprawnie zainstalowane.

Treści powiązane

Po utworzeniu pakietu, który jest plikiem nupkg , możesz opublikować go w wybranej galerii. Aby uzyskać więcej informacji, zobacz Publikowanie pakietów NuGet.

Możesz również rozszerzyć możliwości pakietu lub obsługiwać inne scenariusze. Aby uzyskać więcej informacji, zobacz następujące artykuły:

• Przechowywanie wersji pakietów
• Support wielu wersji .NET
• Przekształcanie kodu źródłowego i plików konfiguracji
• Tworzenie zlokalizowanych pakietów NuGet
• Budowanie pakietów przedpremierowych
• Ustawianie typu pakietu NuGet
• Tworzenie pakietów NuGet zawierających zestawy do współpracy z COM

Aby zapoznać się z innymi typami pakietów, zobacz następujące artykuły:

• Tworzenie pakietów natywnych
• Tworzenie pakietów symboli (.snupkg)