Organizzazione di progetti e dipendenze correlati per la pubblicazione su nuget

Question

Organizzazione di progetti e dipendenze correlati per la pubblicazione su nuget

#1 da (3 voti)

3

Ho lavorato per scrivere binding .NET per Rollbar , un servizio di segnalazione di errori e messaggi, come Airbrake. La mia libreria funziona bene e viene pubblicata nella galleria NuGet.

Quindi ora voglio portarlo al livello successivo di usabilità e implementare un NLog Estensione per questo. Ciò comporta la scrittura di una schermata di valore del codice e il riferimento alla libreria NLog. È un involucro. Potrei anche implementarne uno per Log4Net.

A questo punto è già diventato indistinto come dovrei organizzarlo e gestirlo con il controllo del codice sorgente e il nuget. Una cosa è certa che ci saranno pacchetti nuget separati in modo che le persone non debbano installare dipendenze che non vogliono.

Le mie domande sono:

Devo creare repository git separati per la libreria di base, l'estensione NLog e l'estensione Log4Net? Sembra che sarebbe più facile tenere traccia delle modifiche in processi di generazione chiaramente separati e simili. Potrebbe rendere più facile contribuire al / i progetto / i ... ma non ne sono sicuro.
Devo fare riferimento alla mia libreria di base Rollbar come dipendenza delle librerie di estensioni, o ILMerge? Il vantaggio di ILMerge è che l'utente ha bisogno solo di un riferimento e di una DLL. La parte dispari è con il controllo delle versioni. Mi piace come avere i numeri di versione che hanno senso quando è cambiata solo la libreria di base, oppure è cambiata solo l'estensione. Inoltre, sembra che nuget non elenchi gli aggiornamenti delle dipendenze dei pacchetti installati, solo per i pacchetti stessi. Vorrei che gli aggiornamenti alla libreria di base diventassero chiari come un aggiornamento che l'utente dovrebbe installare! Suppongo che un modo per farlo sia il bumping di versione dell'estensione e che impostano la versione della libreria delle dipendenze.

Questa è la mia prima incursione nello scrivere una libreria open source e pubblicarla e gestirla. Mi piacerebbe un po 'di feedback da parte di persone che si sono occupate di questo in modo da poterlo fare bene!

Sto usando Albacore per il mio processo di compilazione, per quello che vale.

(Codice corrente: link )

c# builds versioning .net code-organization

posta mroach 21.05.2013 - 16:46

fonte

1 risposta

Leggi altre domande sui tag c# builds versioning .net code-organization

Costruire siti Web: debug veloce senza browser Aiutami a capire i seguenti punti sul modello strategico, come si riferisce al principio aperto / chiuso

score 3 · Accepted Answer

Non mi dispiacerebbe includere una piccola DLL inutile, come parte di un pacchetto più grande, ma non vorrei includere quel e NLog, così da poter usare Rollbar con log4net.

Quindi, se intendi includerli nel pacchetto principale, non rendere il pacchetto dipendente dal prodotto secondario. Perché non è dipendente. Non ho bisogno di NLog per usare Rollbar. Ma, nota che questo significa che sarò in grado di installare qualsiasi versione di NLog al fianco di Rollbar, il che significa che sono fregato se ne scelgo uno che è incompatibile.

Ci sono molti progetti open source su nuget che collegano altri due e hanno nomi combinati, come Rollbar.NLog, che li fa comparire accanto a Rollbar quando sto cercando ma mi dà la possibilità di includerli o no.

Se si utilizza questa opzione, è possibile rendere indipendenti i numeri di versione, impostando le versioni di dipendenza. Ad esempio, tu dici che Rollbar.NLog v1.2 richiede Rollbar v1.x ( il tag dipendenza nel tuo file nuspec , ( id="Rollbar" version="[1.1,1.2)" ) e dammi il permesso di aggiornare i due pacchetti in modo indipendente, purché nessuno dei due sia aggiornato a v2.x.

Se hai un pacchetto Rollbar.NLog, dovresti renderlo dipendente da NLog. Se puoi essere sicuro del versioning di NLog (ad esempio, sarà sempre retrocompatibile, a meno che la versione principale non cambi), allora dammi la libertà anche con quello. Ma tu non devi. Puoi specificare id="NLog" version="[3.2.1]" . Ciò lo rende sicuro per me, ma meno flessibile: la mia strategia di upgrade di NLog è legata alla tua strategia di rilascio.