Hantera uppdateringar av beroenden i .NET-projektet

Slutförd

Förr eller senare vill du uppdatera till en ny version av ett bibliotek. En funktion kanske har markerats som inaktuell, eller så kanske det finns en ny funktion i en senare version av ett paket som du använder.

Tänk på följande saker innan du försöker uppdatera ett bibliotek:

• Typ av uppdatering: Vilken typ av uppdatering är tillgänglig? Är det en liten felkorrigering? Lägger den till en ny funktion som du behöver? Bryter den koden? Du kan kommunicera uppdateringstypen med hjälp av ett system som kallas för semantisk versionshantering. Hur bibliotekets versionsnummer uttrycks kommunicerar med utvecklarna vilken typ av uppdatering de hanterar.
• Om projektet är korrekt konfigurerat: Du kan konfigurera .NET-projektet så att du bara får de typer av uppdateringar du vill ha. Du utför bara en uppdatering om en viss typ av uppdatering är tillgänglig. Vi rekommenderar den här metoden eftersom du inte riskerar att stöta på överraskningar.
• Säkerhetsproblem: Att hantera projektberoenden över tid innebär att vara medveten om problem som kan inträffa. Problem uppstår till exempel när säkerhetsrisker identifieras. Helst släpps korrigeringar som du kan ladda ned. Med .NET Core-verktyget kan du köra en granskning av dina bibliotek för att se om du har paket som bör uppdateras. Det hjälper dig också att vidta lämpliga åtgärder för att åtgärda ett problem.

Använda semantisk versionshantering

Det finns en branschstandard som kallas semantisk versionshantering, vilket är hur du uttrycker den typ av förändring som du eller någon annan utvecklare introducerar i ett bibliotek. Semantisk versionshantering fungerar genom att säkerställa att ett paket har ett versionsnummer och att versionsnumret är indelat i följande avsnitt:

• Huvudversion: Det vänstra talet. Till exempel är 1 det i 1.0.0. En ändring av det här talet innebär att du kan förvänta dig "icke-bakåtkompatibla ändringar" i koden. Du kan behöva skriva om delar av koden.
• Delversion: Mellannumret. Till exempel är 2 det i 1.2.0. En ändring av det här talet innebär att funktioner har lagts till. Din kod bör fortfarande fungera. Det är vanligtvis säkert att acceptera uppdateringen.
• Korrigeringsversion: Det högra numret. Till exempel är 3 det i 1.2.3. En ändring av det här talet innebär att en ändring har tillämpats som åtgärdar något i koden som ska fungera. Det bör vara säkert att godkänna uppdateringen.

I tabellen ser du hur versionsnumret ändras för varje versionstyp:

Typ	Vad händer
Högre version	1.0.0 ändringar i 2.0.0
Delversion	1.1.1 ändringar i 1.2.0
Korrigeringsversion	1.0.1 ändringar i 1.0.2

Många företag och utvecklare använder det här systemet. Om du tänker publicera paket och skicka dem till NuGet-registret förväntas du följa semantisk versionshantering. Även om du bara laddar ned paket från NuGet-registret, kan du förvänta dig att paketen följer den semantiska versionshanteringen.

Ändringar i ett paket kan medföra risker, till exempel risk för en ny bugg som kan skada ditt företag. En del risker kan kräva att du skriver om delar av koden. Att skriva om kod tar tid och kostar pengar.

Uppdateringsmetod

Som .NET-utvecklare kan du kommunicera det uppdateringsbeteende som du vill .NET. Glöm inte vilka olika risker som finns med uppdateringar. Här följer några metoder:

• Huvudversion: Jag är OK med att uppdatera till den senaste huvudversionen så snart den är ute. Jag accepterar det faktum att jag kan behöva ändra kod på min sida.
• Delversion: Jag är OK med en ny funktion som läggs till. Jag vill inte ha kod som inte är bakåtkompatibel.
• Korrigeringsversion: De enda uppdateringar jag är ok med är felkorrigeringar.

Om du hanterar ett nytt eller mindre .NET-projekt, behöver du inte vara så strikt när du definierar uppdateringsstrategin. Du kan till exempel alltid uppdatera till den senaste versionen. I mer komplexa projekt behöver du vara lite försiktigare, men det sparar vi till en senare modul.

I allmänhet, desto mindre beroende du uppdaterar, desto färre beroenden har det och desto mer sannolikt är uppdateringsprocessen enkel.

Konfigurera projektfilen för uppdatering

När du lägger till ett eller flera beroenden konfigurerar du projektfilen så att du får förutsägbart beteende när du återställer, skapar eller kör projektet. Du kan ange vilken metod du vill använda för ett paket. NuGet har begreppen versionsintervall och flytande versioner.

Versionsintervall är en särskild notation som du kan använda för att ange ett visst intervall med versioner som du vill lösa.

Notation	Tillämpad regel	beskrivning
1.0	x >= 1,0	Lägsta version, inklusive
(1.0,)	x > 1.0	Lägsta version, exklusive
[1.0]	x == 1.,0	Exakt versionsmatchning
(,1.0]	x ≤ 1.0	Högsta version, inklusive
(,1.0)	x < 1.0	Högsta version, exklusive
[1.0,2.0]	1.0 ≤ x ≤ 2.0	Exakt intervall, inklusive
(1.0,2.0)	1,0 < x < 2,0	Exakt intervall, exklusive
[1.0,2.0)	1,0 ≤ x < 2,0	Blandat, inklusive lägsta och exklusive högsta version
(1.0)	ogiltig	ogiltig

NuGet stöder också användning av en flytande versionskommentering för större, mindre, korrigerings- och förhandsversionssuffixdelar i talet. Den här notationen är en asterisk (*). Versionsspecifikationen 6.0.* säger till exempel "använd den senaste 6.0.x-versionen". I ett annat exempel betyder 4.* "använd den senaste 4.x-versionen". Om du använder en flytande version minskar ändringarna i projektfilen samtidigt som du håller dig uppdaterad med den senaste versionen av ett beroende.

Kommentar

Vi rekommenderar att du installerar en specifik version i stället för att använda någon av de flytande notationerna. Om du installerar en viss version ser du till att dina versioner kan upprepas om du inte uttryckligen begär en uppdatering av ett beroende.

När du använder en flytande version hämtar NuGet den senaste versionen av ett paket som matchar versionsmönstret. I följande exempel hämtar 6.0.* den senaste versionen av ett paket som börjar med 6.0. Det är version 6.0.1.

Här är några exempel du kan konfigurera för högre version, delversion eller korrigeringsversion:

<!-- Accepts any version 6.1 and later. -->
<PackageReference Include="ExamplePackage" Version="6.1" />

<!-- Accepts any 6.x.y version. -->
<PackageReference Include="ExamplePackage" Version="6.*" />
<PackageReference Include="ExamplePackage" Version="[6,7)" />

<!-- Accepts any later version, but not including 4.1.3. Could be
     used to guarantee a dependency with a specific bug fix. -->
<PackageReference Include="ExamplePackage" Version="(4.1.3,)" />

<!-- Accepts any version earlier than 5.x, which might be used to prevent pulling in a later
     version of a dependency that changed its interface. However, we don't recommend this form because determining the earliest version can be difficult. -->
<PackageReference Include="ExamplePackage" Version="(,5.0)" />

<!-- Accepts any 1.x or 2.x version, but not 0.x or 3.x and later. -->
<PackageReference Include="ExamplePackage" Version="[1,3)" />

<!-- Accepts 1.3.2 up to 1.4.x, but not 1.5 and later. -->
<PackageReference Include="ExamplePackage" Version="[1.3.2,1.5)" />

Hitta och uppdatera inaktuella paket

Kommandot dotnet list package --outdated visar inaktuella paket. Med kommandot kan du se när nyare paketversioner är tillgängliga. Här är ett typiskt resultat från kommandot:

Top-level Package      Requested   Resolved   Latest
> Humanizer            2.7.*       2.7.9      2.8.26

Nedan visas namnen på kolumnerna i utdatan:

• Requested: Den version eller det versionsintervall som du har angett.
• Resolved: Den faktiska versionen som laddats ned för projektet som matchar den angivna versionen.
• Latest: Den senaste versionen som är tillgänglig för uppdatering från NuGet.

Det rekommenderade arbetsflödet är att köra följande kommandon i den här ordningen:

1. Kör dotnet list package --outdated. Kommandot visar alla inaktuella paket. Information visas i kolumnerna Requested, Resolved och Latest.
2. Kör dotnet add package <package name>. Om du kör det här kommandot försöker det uppdatera till den senaste versionen. Du kan också skicka in --version=<version number/range>.