Behandle avhengighetsoppdateringer i .NET-prosjektet

Fullført

Før eller senere vil du oppdatere til en ny versjon av et bibliotek. Kanskje en funksjon er merket som avskrevet, eller kanskje det finnes en ny funksjon i en senere versjon av en pakke du bruker.

Ta hensyn til disse hensynene før du prøver å oppdatere et bibliotek:

• Oppdateringstypen: Hvilken type oppdatering er tilgjengelig? Er det en liten feilretting? Legger den til en ny funksjon du trenger? Bryter den koden? Du kan formidle oppdateringstypen ved hjelp av et system som kalles semantisk versjonskontroll. Måten bibliotekets versjonsnummer uttrykkes på, kommuniserer til utviklere hvilken type oppdatering de arbeider med.
• Om prosjektet er riktig konfigurert: Du kan konfigurere .NET-prosjektet slik at du bare får de typene oppdateringer du ønsker. Du utfører bare en oppdatering hvis en bestemt type oppdatering er tilgjengelig. Vi anbefaler denne tilnærmingen, fordi du ikke risikerer å få overraskelser.
• Sikkerhetsproblemer: Administrasjon av prosjektavhengigheter over tid innebærer å være klar over problemer som kan oppstå. Problemer oppstår etter hvert som sårbarheter oppdages, for eksempel. Ideelt sett utgis oppdateringer som du kan laste ned. .NET Core-verktøyet hjelper deg med å kjøre en overvåking på bibliotekene for å finne ut om du har pakker som skal oppdateres. Det hjelper deg også med å utføre de nødvendige handlingene for å løse et problem.

Bruk semantisk versjonskontroll

Det finnes en bransjestandard kalt semantisk versjonskontroll, som er hvordan du uttrykker endringstypen du eller en annen utvikler introduserer i et bibliotek. Semantisk versjonskontroll fungerer ved å sikre at en pakke har et versjonsnummer, og at versjonsnummeret er delt inn i disse delene:

• hovedversjon: Tallet lengst til venstre. Det er for eksempel 1 i 1.0.0. En endring i dette nummeret betyr at du kan forvente å «bryte endringer» i koden. Du må kanskje skrive om en del av koden.
• underordnet versjon: Det midterste tallet. Det er for eksempel 2 i 1.2.0. En endring av dette tallet betyr at funksjoner ble lagt til. Koden skal fortsatt fungere. Det er vanligvis trygt å godta oppdateringen.
• Patch-versjon: Tallet lengst til høyre. Det er for eksempel 3 i 1.2.3. En endring av dette tallet betyr at det ble brukt en endring som løser noe i koden som skal fungere. Det bør være trygt å godta oppdateringen.

Denne tabellen illustrerer hvordan versjonsnummeret endres for hver versjonstype:

Type	Hva skjer
Hovedversjon	1.0.0 endringer i 2.0.0
Underordnet versjon	1.1.1 endringer i 1.2.0
Oppdateringsversjon	1.0.1 endringer i 1.0.2

Mange bedrifter og utviklere bruker dette systemet. Hvis du har tenkt å publisere pakker og sende dem til NuGet-registeret, forventes det at du følger semantisk versjonskontroll. Selv om du bare laster ned pakker fra NuGet-registeret, kan du forvente at disse pakkene følger semantisk versjonskontroll.

Endringer i en pakke kan føre til risiko, inkludert risikoen for at en feil kan skade bedriften din. Noen risikoer kan kreve at du skriver om en del av koden. Omskriving av kode tar tid og koster penger.

Oppdateringstilnærming

Som .NET-utvikler kan du formidle oppdateringsvirkemåten du vil ha til .NET. Tenk på oppdatering når det gjelder risiko. Her er noen fremgangsmåter:

• hovedversjon: Jeg er ok med å oppdatere til den nyeste hovedversjonen så snart den er ute. Jeg aksepterer det faktum at jeg kanskje må endre kode på slutten min.
• underordnet versjon: Jeg er OK med en ny funksjon som legges til. Jeg er ikke ok med kode som bryter.
• Patch-versjon: De eneste oppdateringene jeg er OK med, er feilrettinger.

Hvis du administrerer et nytt eller mindre .NET-prosjekt, har du råd til å være løs med hvordan du definerer oppdateringsstrategien. Du kan for eksempel alltid oppdatere til den nyeste versjonen. For mer komplekse prosjekter er det mer nyanser, men vi lagrer det for en fremtidig modul.

Jo mindre avhengighet du oppdaterer, jo færre avhengigheter har den, og jo mer sannsynlig er det at oppdateringsprosessen er enkel.

Konfigurer prosjektfilen for oppdatering

Når du legger til én eller flere avhengigheter, konfigurerer du prosjektfilen slik at du får forutsigbar virkemåte når du gjenoppretter, bygger eller kjører prosjektet. Du kan formidle tilnærmingen du vil ta for en pakke. NuGet har begrepene versjonsområder og flytende versjoner.

Versjonsområder er en spesiell notasjon som du kan bruke til å angi et bestemt versjonsområde som du vil løse.

Notasjon	Brukt regel	Beskrivelse
1.0	x >= 1,0	Minimumsversjon, inkludert
(1.0,)	x > 1,0	Minimumsversjon, eksklusiv
[1.0]	x == 1,0	Nøyaktig versjonss match
(,1.0]	x ≤ 1.0	Maksimumsversjon, inklusive
(,1.0)	x < 1,0	Maksimumsversjon, eksklusiv
[1.0,2.0]	1,0 ≤ x ≤ 2,0	Nøyaktig område, inklusive
(1.0,2.0)	1,0 < x < 2,0	Nøyaktig område, eksklusivt
[1.0,2.0)	1,0 ≤ x < 2,0	Blandet inkluderende minimums- og eksklusiv maksimumsversjon
(1.0)	ugyldig	ugyldig

NuGet støtter også bruk av en flytende versjon notasjon for store, mindre, patch og prerelease suffiks deler av tallet. Denne notasjonen er en stjerne (*). Versjonsspesifikasjonen 6.0.* sier for eksempel «bruk den nyeste 6.0.x-versjonen». I et annet eksempel betyr 4.* «bruk den nyeste 4.x-versjonen». Hvis du bruker en flytende versjon, reduseres endringer i prosjektfilen samtidig som du holder deg oppdatert med den nyeste versjonen av en avhengighet.

Notat

Vi anbefaler at du installerer en bestemt versjon i stedet for å bruke noen av de flytende notasjonene. Hvis du installerer en bestemt versjon, sikrer du at byggene kan gjentas med mindre du eksplisitt ber om en oppdatering til en avhengighet.

Når du bruker en flytende versjon, løser NuGet den nyeste versjonen av en pakke som samsvarer med versjonsmønsteret. I eksemplet nedenfor får 6.0.* den nyeste versjonen av en pakke som starter med 6.0. Den versjonen er 6.0.1.

Her er noen eksempler som kan konfigureres for hovedversjon, underordnet eller oppdateringsversjon:

<!-- 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)" />

Finne og oppdatere utdaterte pakker

Kommandoen dotnet list package --outdated viser utdaterte pakker. Denne kommandoen kan hjelpe deg med å lære når nyere versjoner av pakker er tilgjengelige. Her er en vanlig utdata fra kommandoen:

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

Her er betydningene av navnene på kolonnene i utdataene:

• Requested: Versjons- eller versjonsområdet du har angitt.
• Resolved: Den faktiske versjonen som er lastet ned for prosjektet som samsvarer med den angitte versjonen.
• Latest: Den nyeste versjonen som er tilgjengelig for oppdatering fra NuGet.

Den anbefalte arbeidsflyten er å kjøre følgende kommandoer i denne rekkefølgen:

1. Kjør dotnet list package --outdated. Denne kommandoen viser alle utdaterte pakker. Den inneholder informasjon i kolonnene Requested, Resolvedog Latest.
2. Kjør dotnet add package <package name>. Hvis du kjører denne kommandoen, prøver den å oppdatere til den nyeste versjonen. Du kan eventuelt sende inn --version=<version number/range>.