Megosztás a következőn keresztül:


Csomag létrehozása a nuget.exe parancssori felületével

Függetlenül attól, hogy mit tesz a csomagja, vagy milyen kódot tartalmaz, az egyik CLI-eszköz, akár nuget.exe, akár dotnet.exe, segítségével csomagolhatja azt a funkciót egy olyan összetevőbe, amelyet megoszthat és használhat bármely más fejlesztő. A NuGet CLI-eszközök telepítéséhez lásd: NuGet-ügyféleszközök telepítése. Vegye figyelembe, hogy a Visual Studio nem tartalmaz automatikusan cli-eszközt.

Technikailag a NuGet-csomag csak egy zip-fájl, amelyet átneveztek a .nupkg kiterjesztéssel, és amelynek tartalma megfelel bizonyos konvencióknak. Ez a témakör az említett konvencióknak megfelelő csomag létrehozásának részletes folyamatát ismerteti.

A csomagolás a lefordított kóddal (szerelvényekkel), szimbólumokkal és/vagy más, csomagként kézbesítendő fájlokkal kezdődik (lásd : Áttekintés és munkafolyamat). Ez a folyamat független attól, hogy összeállítja vagy más módon hozza létre a csomagba kerülő fájlokat, bár a projektfájl információinak felhasználásával szinkronban tarthatja a lefordított összeállításokat és csomagokat.

Fontos

Ez a témakör nem SDK-stílusú projektekre vonatkozik, jellemzően a Visual Studio 2017-et és újabb verziókat használó .NET Core- és .NET Standard-projekteken és a NuGet 4.0+-n kívüli projektekre.

Döntse el, hogy mely szerelvényeket csomagolja be

A legtöbb általános célú csomag egy vagy több szerelvényeket tartalmaz, amelyeket más fejlesztők a saját projektjeikben használhatnak.

  • Általánosságban elmondható, hogy a legjobb, ha NuGet-csomagonként egy szerelvény van, feltéve, hogy minden egyes szerelvény egymástól függetlenül hasznos. Ha például van egy Utilities.dll, amely függ Parser.dll attól, és Parser.dll önmagában hasznos, hozzon létre külön csomagot mindegyikhez. Ez lehetővé teszi a fejlesztők számára, hogy a Parser.dll függetlenül használják a Utilities.dll-től.

  • Ha a kódtár több olyan összeállításból áll, amelyek egymástól függetlenül nem hasznosak, akkor rendben van, ha egyetlen csomagban egyesítjük őket. Az előző példában, ha Parser.dll csak Utilities.dll által használt kódot tartalmaz, akkor megfelelő, ha Parser.dll ugyanabban a csomagban marad.

  • Fontos, hogy hasonlóképpen, ha Utilities.dll függ Utilities.resources.dll-től, ahol az utóbbi önmagában nem hasznos, akkor mindkettőt ugyanabba a csomagba helyezze.

Az erőforrások valójában különleges esetek. Amikor egy csomag telepítve van egy projektben, a NuGet automatikusan szerelvényhivatkozásokat ad hozzá a csomag DLL-jeihez, kivéve azokat, amelyek neve azért van elnevezve .resources.dll , mert feltételezzük, hogy honosított műholdas szerelvények (lásd: Honosított csomagok létrehozása). Ezért kerülje az olyan fájlok használatát .resources.dll , amelyek egyébként alapvető csomagkódot tartalmaznak.

Ha a kódtár COM-interop szerelvényeket tartalmaz, kövesse a com-interop szerelvényekkel rendelkező csomagok létrehozása című témakör útmutatását.

A .nuspec fájl szerepe és szerkezete

Ha már tudja, hogy mely fájlokat szeretné csomagolni, a következő lépés egy csomagjegyzék létrehozása EGY .nuspec XML-fájlban.

A jegyzék:

  1. A csomag tartalmát ismerteti, és magában a csomagban is szerepel.
  2. A csomag létrehozását is vezérli, és utasítja a NuGetet a csomag projektbe való telepítésére. A jegyzék például más csomagfüggőségeket azonosít, például hogy a NuGet a fő csomag telepítésekor is telepítheti ezeket a függőségeket.
  3. A szükséges és az opcionális tulajdonságokat is tartalmazza az alábbiak szerint. A pontos részletekért, beleértve az itt nem említett egyéb tulajdonságokat is, tekintse meg a .nuspec referenciát.

Kötelező tulajdonságok:

  • A csomagazonosító, amelynek egyedinek kell lennie a csomagot üzemeltető katalógusban.
  • Egy adott verziószám a Major.Minor.Patch[-Utótag] formában, ahol a -Utótag azonosítja a kiadás előtti verziókat
  • A csomag címe, ahogy a kiszolgálón megjelenjen (például nuget.org)
  • Szerzői és tulajdonosi adatok.
  • A csomag hosszú leírása.

Gyakori választható tulajdonságok:

Az alábbiak egy tipikus (de fiktív) .nuspec fájl, a tulajdonságokat leíró megjegyzésekkel:

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

A függőségek deklarálásáról és a verziószámok megadásáról további információt apackages.config és a Csomag verziószámozása című témakörben talál. Az erőforrásokat közvetlenül a függőségekből is felszínre lehet hozni a include és exclude attribútumok dependency elemen való használatával. Lásd .nuspec Reference - Dependencies.

Mivel a jegyzék szerepel a belőle létrehozott csomagban, a meglévő csomagok vizsgálatával bármilyen további példát találhat. Jó forrás a számítógépen található globális csomagok mappa, amelynek helyét a következő parancs adja vissza:

nuget locals -list global-packages

Lépjen bármelyik csomag\verzió mappába, másolja a .nupkg fájlt egy .zip fájlba, majd nyissa meg a .zip fájlt, és vizsgálja meg a .nuspec benne lévő fájlt.

Megjegyzés:

Visual Studio-projektből .nuspec létrehozásakor a jegyzék olyan elemeket tartalmaz, amelyeket a csomag összeállításakor a projekt adatai helyettesítenek be. Lásd : A .nuspec létrehozása Visual Studio-projektből.

A .nuspec fájl létrehozása

A teljes jegyzék létrehozása általában egy alapszintű .nuspec fájllal kezdődik, amely az alábbi módszerek egyikével jön létre:

Ezután kézzel szerkessze a fájlt, hogy az pontosan leírja a végleges csomagban kívánt tartalmat.

Fontos

A létrehozott .nuspec fájlok olyan helyőrzőket tartalmaznak, amelyeket módosítani kell, mielőtt létrehozták a csomagot a nuget pack paranccsal. Ez a parancs meghiúsul, ha a .nuspec rendszer tartalmaz helyőrzőket.

Egy konvenció alapú munkakönyvtárból

Mivel a NuGet-csomagok csak a kiterjesztéssel .nupkg átnevezett ZIP-fájlok, gyakran a legegyszerűbb létrehozni a kívánt mappastruktúrát a helyi fájlrendszerben, majd közvetlenül ebből a struktúrából létrehozni a .nuspec fájlt. A nuget pack parancs ezután automatikusan hozzáadja az összes fájlt ebben a mappastruktúrában (kivéve azokat a mappákat, amelyek kezdődnek ., így a privát fájlok ugyanabban a struktúrában maradnak).

Ennek a megközelítésnek az az előnye, hogy nem kell megadnia a jegyzékben, hogy mely fájlokat szeretné belefoglalni a csomagba (a jelen témakör későbbi részében leírtak szerint). Egyszerűen beállíthatja, hogy a buildelési folyamat pontosan a csomagba tartozó mappastruktúrát hozza létre, és könnyen felvehet más fájlokat is, amelyek egyébként nem részei a projektnek:

  • A célprojektbe injektálandó tartalom és forráskód.
  • PowerShell-szkriptek
  • Átalakítások egy projekt meglévő konfigurációs és forráskódfájljaira.

A mappaegyezmények a következők:

Mappa Description Művelet a csomag telepítésekor
(root) A readme.txt helye A Visual Studio egy readme.txt fájlt jelenít meg a csomag gyökerében a csomag telepítésekor.
lib/{tfm} Az adott Target Framework Moniker (TFM) szerelvényfájljai (.dll), dokumentációi (.xml) és szimbólumfájljai (.pdb) A assemblyk a fordításhoz és futtatás közben referenciaként hozzáadva; .xml és .pdb a projektmappákba másolódnak. Lásd: Több cél keretrendszer támogatása a keretrendszer célspecifikus almappáinak létrehozásához.
ref/{tfm} Az adott Target Framework Moniker (TFM) szerelvényfájljai (.dll) és szimbólumai (.pdb) Az assembly-k csak fordítási időhöz lesznek hozzáadva hivatkozásként; így semmilyen fájl nem lesz átmásolva a projekt bin mappájába.
futtatókörnyezetek Architektúraspecifikus szerelvény (.dll), szimbólum (.pdb) és natív erőforrásfájl (.pri) Az összetevők csak mint futásidejű referenciák lesznek hozzáadva; más fájlok a projektmappákba másolódnak. A mappában /ref/{tfm} mindig lennie kell egy megfelelő (TFM) AnyCPU szerelvénynek, amely biztosítja a megfelelő fordítási idő szerelvényt. Lásd : Több cél keretrendszer támogatása.
tartalom Tetszőleges fájlok A rendszer a tartalmat a projekt gyökerére másolja. Gondoljon a tartalommappára úgy, mint a csomagot végső soron használó célalkalmazás gyökerére. Ha azt szeretné, hogy a csomag hozzáadjon egy képet az alkalmazás /images mappájába, helyezze el a csomag tartalom/képek mappájába.
build (3.x+) MSBuild .targets és .props fájlok Automatikusan beszúrva a projektbe.
buildMultiTargeting (4,0+) MSBuild .targets és .props fájlok a keretrendszerek közötti célzáshoz Automatikusan beszúrva a projektbe.
buildTransitive (5,0+) MSBuild .targets és .props fájlok, amelyek tranzitívan átkerülnek minden fogyasztó projektbe. Tekintse meg a szolgáltatásoldalt . Automatikusan beszúrva a projektbe.
eszközök A Package Manager konzolról elérhető PowerShell-szkriptek és programok A tools mappa csak a PATH Package Manager-konzol környezeti változójába lesz hozzáadva (pontosabban nem az PATH MSBuild-hez beállítotthoz a projekt létrehozásakor).

Mivel a mappastruktúra tetszőleges számú szerelvényt tartalmazhat tetszőleges számú célkerethez, ez a módszer több keretrendszert támogató csomagok létrehozásakor szükséges.

Mindenesetre a kívánt mappastruktúra létrehozása után futtassa a következő parancsot a mappában a .nuspec fájl létrehozásához:

nuget spec

A létrehozott .nuspec fájl nem tartalmaz explicit hivatkozásokat a mappastruktúrában lévő fájlokra. A NuGet automatikusan tartalmazza az összes fájlt a csomag létrehozásakor. Azonban a jegyzék más részeiben továbbra is szerkesztenie kell a helyőrzőértékeket.

DLL-ből származó szerelvény

Egy egyszerű összeállításból származó csomag létrehozása esetén a következő paranccsal generálhat fájlt az összeállítás metaadataiból: .nuspec

nuget spec <assembly-name>.dll

Az űrlap használata a manifesztben szereplő néhány helyőrzőt lecseréli az assembly adott értékeire. A tulajdonság például a <id> szerelvény nevére van állítva, és <version> a szerelvény verziójára van állítva. A jegyzék többi tulajdonságának azonban nincs megfelelő értéke az alkalmazásban, ezért továbbra is helyőrzőket tartalmaznak.

Visual Studio-projektből

.nuspec fájl létrehozása .csproj vagy .vbproj fájlból kényelmes, mert a projekthez telepített egyéb csomagokra automatikusan hivatkozik függőségként a rendszer. Egyszerűen használja a következő parancsot a projektfájllal megegyező mappában:

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

Az eredményül kapott <project-name>.nuspec fájl olyan tokeneket tartalmaz, amelyeket a csomagoláskor helyettesítenek a projektből származó értékekkel, beleértve a már telepített többi csomagra vonatkozó referenciákat is.

Ha be kell vonnia csomagfüggőségeket a .nuspec fájlba, inkább használja nuget pack, és szerezze meg a .nuspec fájlt a létrehozott .nupkg fájlból. Használja például a következő parancsot.

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

A tokent a projekt tulajdonság mindkét oldalán $ szimbólumok határolják. Például az <id> így létrehozott jegyzékben szereplő érték általában a következőképpen jelenik meg:

<id>$id$</id>

A token-t a projektfájl AssemblyName értékére cseréli a csomagoláskor. A projektértékek .nuspec tokenekre történő pontos leképezéséről lásd a Csere tokenek hivatkozást.

A jogkivonatok megszabadítják Önt attól, hogy frissítenie kelljen a fontos értékeket, mint például a verziószámot a .nuspec-ben, amikor frissíti a projektet. (A tokeneket szükség esetén literálokra cserélheti).

Vegye figyelembe, hogy a Visual Studio-projektből való munka során számos további csomagolási lehetőség áll rendelkezésre a .nupkg fájl későbbi létrehozásához a Nuget-csomag futtatása című cikkben leírtak szerint.

Megoldásszintű csomagok

Csak NuGet 2.x. A NuGet 3.0+-ban nem érhető el.

A NuGet 2.x támogatja a megoldásszintű csomag fogalmát, amely eszközöket vagy további parancsokat telepít a Package Manager-konzolhoz (a tools mappa tartalmához), de nem ad hozzá hivatkozásokat, tartalmakat és nem készít testreszabásokat a megoldásban lévő projektekhez. Az ilyen csomagok nem tartalmaznak fájlokat a közvetlen lib, content vagy build mappáikban, és egyik függőségük sem tartalmaz fájlokat a saját lib, content vagy build mappáikban.

A NuGet a telepített megoldásszintű csomagokat nem a projekt packages.config fájljában, hanem a .nuget mappában lévő packages.config fájlban követi nyomon.

Új fájl alapértelmezett értékekkel

Az alábbi parancs egy alapértelmezett jegyzékfájlt hoz létre helyőrzőkkel, amely biztosítja, hogy a megfelelő fájlstruktúrával kezdje:

nuget spec [<package-name>]

Ha kihagyja <a csomag nevét>, az eredményül kapott fájl a következő Package.nuspec: . Ha például Contoso.Utility.UsefulStuff nevet ad meg, a fájl Contoso.Utility.UsefulStuff.nuspec lesz.

Az eredmény olyan .nuspec értékek helyőrzőit tartalmazza, mint a projectUrl. A végleges .nupkg fájl létrehozása előtt mindenképpen szerkessze a fájlt.

Egyedi csomagazonosító kiválasztása és a verziószám beállítása

A csomagazonosító (<id> elem) és a verziószám (<version> elem) a jegyzék két legfontosabb értéke, mivel egyedileg azonosítják a csomagban található pontos kódot.

Ajánlott eljárások a csomagazonosítóhoz:

  • Egyediség: Az azonosítónak egyedinek kell lennie az egész nuget.org, vagy bármely katalógusban, amely a csomagot üzemelteti. Mielőtt eldöntené az azonosítót, keressen rá a megfelelő katalógusban, és ellenőrizze, hogy a név már használatban van-e. Az ütközések elkerülése érdekében érdemes a cég nevét használni az azonosító első részeként, például Contoso..
  • Névtérszerű nevek: Kövesse a .NET névtereihez hasonló mintát, kötőjelek helyett pont jelölést használva. Például használja Contoso.Utility.UsefulStuff ahelyett Contoso-Utility-UsefulStuff vagy Contoso_Utility_UsefulStuff. A felhasználók akkor is hasznosnak találják, ha a csomagazonosító megegyezik a kódban használt névterekével.
  • Mintacsomagok: Ha olyan mintakódot tartalmazó csomagot hoz létre, amely bemutatja, hogyan használható egy másik csomag, csatolja .Sample utótagként az azonosítóhoz, ahogyan az a .Contoso.Utility.UsefulStuff.Sample (A mintacsomag természetesen függ a másik csomagtól.) Mintacsomag létrehozásakor használja a korábban ismertetett konvencióalapú munkakönyvtár-módszert. Az content mappában rendezze el a mintakódot egy \Samples\<identifier> nevű mappában úgy, mint ahogyan az \Samples\Contoso.Utility.UsefulStuff.Sample van.

Ajánlott eljárások a csomagverzióhoz:

  • Általában állítsa be a csomag verzióját a kódtárnak megfelelőre, bár ez nem feltétlenül szükséges. Ez egy egyszerű kérdés, ha egyetlen szerelvényre korlátozza a csomagokat, amint azt korábban a döntésben leírtuk, hogy melyik szerelvényeket kell csomagolni. Ne feledje, hogy a NuGet maga a csomagverziókkal foglalkozik a függőségek feloldásakor, nem pedig a szerelvényverziókkal.
  • Nem szabványos verzióséma használata esetén mindenképpen vegye figyelembe a NuGet verziószámozási szabályait a Csomag verziószámozása című témakörben leírtak szerint.

A következő rövid blogbejegyzések is hasznosak a verziószámozás megértéséhez:

Readme és egyéb fájlok hozzáadása

Ha közvetlenül meg szeretné adni a csomagban felvenni kívánt fájlokat, használja a <files>.nuspec fájl csomópontot, amely a következő címkét <metadata>:

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

Jótanács

A konvencióalapú munkakönyvtár-megközelítés használata esetén a readme.txt fájlt a csomag gyökérkönyvtárába helyezheti, míg az egyéb tartalmakat a content mappába. A jegyzékben nincs szükség <file> elemekre.

Ha a csomag gyökerében található egy readme.txt nevű fájl, a Visual Studio közvetlenül a csomag telepítése után sima szöveges formában jeleníti meg a fájl tartalmát. (A Readme fájlok nem jelennek meg a függőségként telepített csomagoknál.) Így néz ki például a HtmlAgilityPack csomag README fájlja:

Egy NuGet-csomag olvasási fájljának megjelenítése a telepítéskor

Megjegyzés:

Ha a .nuspec fájlba egy üres <files> csomópontot is beilleszt, akkor a NuGet csak a lib mappában található tartalmat foglalja bele a csomagba.

MSBuild kellékek és célok belefoglalása egy csomagba

Bizonyos esetekben előfordulhat, hogy egyéni buildcélokat vagy tulajdonságokat szeretne hozzáadni a csomagot használó projektekhez, például egyéni eszköz vagy folyamat futtatásához a buildelés során. További információ az MSBuild kellékeiről és céljairól a NuGet-csomagokban

Hozzon létre <package_id>.targets vagy <package_id>.props (például Contoso.Utility.UsefulStuff.targets) a projekt build mappáiban.

Ezután a .nuspec fájlban mindenképpen tekintse meg ezeket a fájlokat a <files> csomóponton:

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

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

Amikor csomagokat ad hozzá egy projekthez, a NuGet automatikusan tartalmazza ezeket a kellékeket és célokat.

A "nuget pack" parancs futtatásával létrehozhatja a .nupkg fájlt.

Szerelvény vagy konvencióalapú munkakönyvtár használatakor hozzon létre egy csomagot úgy, hogy futtatja a .nuspec fájlt a nuget pack paranccsal, és cserélje le a <project-name> címkét a konkrét fájlnevére.

nuget pack <project-name>.nuspec

Visual Studio-projekt használatakor futtassa nuget pack, amely automatikusan betölti a .nuspec fájlt, és lecseréli a benne lévő jogkivonatokat a projektfájlban található értékekkel.

nuget pack <project-name>.csproj

Megjegyzés:

A projektfájl közvetlen használata szükséges a jogkivonat cseréjéhez, mert a projekt a jogkivonat értékeinek forrása. A tokencsere nem történik meg, ha nuget pack fájlt használ .nuspec.

Minden esetben azokat a mappákat, amelyek ponttal kezdődnek, kizárja, például .git vagy .hg.

A NuGet azt jelzi, hogy vannak-e olyan hibák a .nuspec fájlban, amelyeket javítani kell, például elfelejti módosítani a helyőrző értékeket a jegyzékben.

Ha nuget pack sikerül, rendelkezik egy .nupkg fájllal, amelyet közzétehet egy megfelelő gyűjteményben a Csomag közzététele című cikkben leírtak szerint.

Jótanács

A csomag létrehozása után egy hasznos módja a vizsgálatnak, ha megnyitja a Csomagfelfedező eszközben. Ez grafikus nézetet biztosít a csomag tartalmáról és a jegyzékről. Az eredményül kapott .nupkg fájlt átnevezheti egy .zip fájlra, és közvetlenül megvizsgálhatja annak tartalmát.

További lehetőségek

A különböző parancssori kapcsolókkal nuget pack kizárhatja a fájlokat, felülbírálhatja a jegyzékben szereplő verziószámot, és módosíthatja a kimeneti mappát, többek között más funkciókkal. A teljes listát a csomagparancsok hivatkozásában találja.

A Visual Studio-projektekben az alábbi lehetőségek közül választhat:

  • Hivatkozott projektek: Ha a projekt más projektekre hivatkozik, a csomag részeként vagy függőségként is hozzáadhatja a hivatkozott projekteket a -IncludeReferencedProjects következő beállítással:

    nuget pack MyProject.csproj -IncludeReferencedProjects
    

    Ez a befogadási folyamat rekurzív, ezért ha MyProject.csproj a B és a C projektre hivatkozik, és ezek a projektek A, E és F hivatkozásra hivatkoznak, akkor a B, C, D, E és F fájlokat a csomag tartalmazza.

    Ha egy hivatkozott projekt saját fájlt tartalmaz .nuspec , akkor a NuGet függőségként adja hozzá a hivatkozott projektet. A projektet külön kell csomagolnia és közzétennie.

  • Buildkonfiguráció: A NuGet alapértelmezés szerint a projektfájl alapértelmezett buildkonfigurációját használja, általában hibakeresést. Ha más buildkonfigurációból (például kiadásból) szeretne fájlokat csomagolni, használja a -properties beállítást a konfigurációval:

    nuget pack MyProject.csproj -properties Configuration=Release
    
  • Szimbólumok: ha olyan szimbólumokat szeretne tartalmazni, amelyek lehetővé teszik a fogyasztók számára, hogy végiglépkedjenek a csomagkódon a hibakeresőben, használja a -Symbols következő lehetőséget:

    nuget pack MyProject.csproj -symbols
    

Csomag telepítésének tesztelése

A csomagok közzététele előtt általában tesztelni kell a csomag projektbe való telepítésének folyamatát. A tesztek biztosítják, hogy a feltétlenül szükséges fájlok a projekt megfelelő helyeihez kerülnek.

A telepítéseket manuálisan is tesztelheti a Visual Studióban vagy a parancssorban a normál csomagtelepítési lépésekkel.

Az automatizált teszteléshez az alapfolyamat a következő:

  1. Másolja a .nupkg fájlt egy helyi mappába.
  2. Adja hozzá a mappát a csomagforrásokhoz a nuget sources add -name <name> -source <path> parancs használatával (lásd : nuget-források). Vegye figyelembe, hogy ezt a helyi forrást csak egyszer kell beállítania egy adott számítógépen.
  3. Telepítse a csomagot abból a forrásból, ahol nuget install <packageID> -source <name> a forrás neve megegyezik a megadott <name>névvelnuget sources. A forrás megadása biztosítja, hogy a csomag csak az adott forrásból legyen telepítve.
  4. Vizsgálja meg a fájlrendszert, és ellenőrizze, hogy a fájlok megfelelően vannak-e telepítve.

Következő lépések

Miután létrehozott egy csomagot, amely egy .nupkg fájl, közzéteheti azt az Ön által választott gyűjteményben, a csomag közzétételekor leírtak szerint.

Érdemes lehet kibővíteni a csomag képességeit, vagy más módon támogatni az alábbi témakörökben ismertetett egyéb forgatókönyveket:

Végül további csomagtípusokat is figyelembe kell venni: