Politiche sulle versioni delle dipendenze di NuGet durante lo sviluppo di una libreria

Question

Politiche sulle versioni delle dipendenze di NuGet durante lo sviluppo di una libreria

#1 da (5 voti)
#2 da (0 voti)

5

Sto costruendo una libreria C # e ho alcune dipendenze attraverso i pacchetti NuGet. Sto cercando di ridurre al minimo la barriera di accesso e utilizzare le versioni molto precoci dei pacchetti di dipendenze. Ad esempio, uso Newtonsoft.Json di v6.0.1, ma la versione corrente è v9x.

Questo è per i casi in cui le persone installano il mio pacchetto, ma non hanno l'ultima versione di Json.Net - per non costringerlo ad aggiornare i propri riferimenti. Funziona, ma non mi piace molto - Devo lavorare con una versione di libreria obsoleta. E per i casi in cui le persone hanno effettivamente l'ultima versione, sono costretti ad aggiungere bindingRedirect al loro app.config o web.config .

Esiste un modo migliore per gestire l'inferno delle versioni? spero in qualche magia in cui posso dire "compilami questo codice, includi questa libreria dipendente, ma ignora il numero di versione". È possibile?

c# .net dependency-management nuget

posta trailmax 18.11.2016 - 00:24

fonte

2 risposte

0

Per seguire la mia soluzione: prendo in carico tutte le ultime versioni delle librerie di cui ho bisogno, il pacchetto NuGet che produco specifica la dipendenza dalle ultime versioni dei pacchetti NuGet dipendenti.

Per risolvere il problema della versione precedente delle librerie nel codice client bindingRedirect in web.config o app.config può essere applicato per puntare a qualunque versione della libreria sia installata:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="X.X.X.X" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

dove X.X.X.X è la versione installata della libreria. Anche se in questo caso i client dovranno fare attenzione durante l'installazione del mio NuGet in modo che le loro dipendenze non vengano aggiornate.

risposta data 30.11.2016 - 12:34

fonte

Leggi altre domande sui tag c# .net dependency-management nuget

Struttura DB per il rilevamento della somiglianza DDD, dove utilizzare i servizi di infrastruttura

score 5 · Accepted Answer

Non esiste un inferno per le versioni. Questo è specificamente l'obiettivo di NuGet: le diverse versioni dello stesso pacchetto possono essere installate fianco a fianco. L'unica limitazione è che non puoi fare riferimento a versioni differenti nello stesso progetto . Ma quali versioni delle librerie fanno riferimento ai pacchetti da cui dipendo sono irrilevanti per il mio progetto.

Nella maggior parte dei casi, non puoi nemmeno evitare questa situazione se usi librerie di terze parti. Immagina di dipendere dalla libreria di terze parti A e dalla libreria di terze parti B. La libreria A utilizza una versione specifica di Json.Net. La libreria B utilizza un'altra versione. cosa fai? Chiede all'autore di una di queste librerie di aggiornare o downgrade delle dipendenze? Butti una delle biblioteche e trascorri i prossimi due anni riscrivendola solo per utilizzare una versione specifica di Json.Net?

Come autore di una libreria, non dovresti preoccuparti della versione di Json.Net che i tuoi clienti usano nei loro progetti, o delle versioni di Json.Net usate dalle librerie di terze parti, perché hai vinto non sbagliare comunque. Un cliente utilizzerà la versione 6; un'altra versione 8. La libreria verrà installata parallelamente ad altre librerie utilizzando la versione 7 e quelle che utilizzano la versione 9.

This is for cases when people install my package, but don't have the latest version of Json.Net - not to force them to update their references.

Funziona in un raro caso di persone che stanno usando la versione 6.0.1 della libreria. E fallisce per tutti coloro che usano la versione 6.0.0. E 5. *. E 4. *. E 6.0.2. E 6.0.3. Ottieni l'immagine.

L'unica cosa di cui ti dovresti occupare è l'immagine che dai del tuo progetto. Se utilizzi una versione obsoleta, le persone potrebbero pensare:

Ew, this looks old. Why is this guy using a library which is not used any longer for the last three years? I think he just doesn't maintain his project any longer. I'll try one which is actually maintained.

D'altra parte, se stai utilizzando la versione più recente di una libreria di terze parti, cosa potrebbe accadere? La persona potrebbe scoprire che la tua libreria sta utilizzando una versione più recente e decide di aggiornare il proprio progetto. Oppure continua a utilizzare la versione precedente, perché anche questa è una scelta valida.