Nell’applicazione MultiClock, per poter permettere di selezionare i colori, abbiamo utilizzato l’Extended WPF Toolkit, un progetto derivato da una libreria in origine sviluppata gratuitamente da Microsoft, ora presa in carico da Exceed, che mantiene una versione community dei controlli gratuita. Per fare questo, abbiamo utilizzato NuGet, che è un servizio che permette di pubblicare e rendere disponibili agli sviluppatori molti e diversi tipi di componenti che possono essere scaricati e usati con un semplice reference da Visual Studio.
Oggi, ho ripreso in mano le librerie comuni di DotNetwork, che ho implementato in svariati articoli negli anni passati e mi sono accorta che utilizzavano la vecchia libreria di controlli del Toolkit, pertanto ho dovuto aggiornare la libreria da NuGet anche in quei progetti. Quando l’ho fatto però, mi sono posta la seguente domanda: Ma è davvero cosa buona avere lo stesso pacchetto NuGet scaricato in tutte le librerie e le applicazioni che sviluppo adesso e svilupperò in futuro?
Quali sono i vantaggi?
- Le librerie sono automaticamente aggiornate da visual studio, pertanto se non vi sono stranezze, come funzionano a me, funzioneranno anche a chi scarica i progetti
- La versione della libreria installata viene controllata e mantenuta automaticamente
- Non devo manutenere un progetto per gestire le librerie di terze parti
Quali sono gli svantaggi?
- Il download di una copia delle librerie per ognuno dei progetti che le usa, quindi 100 progetti 100 copie
- Se in un progetto usiamo 2 componenti (2 dll) e questi due componenti usano due diverse versioni di una libreria NuGet, potremmo trovarci ad avere problemi di versioning.
- Se per caso ci troviamo offline, come possiamo fare un reference? Sfortunatamente non siamo sempre coperti da servizi di rete quando andiamo da clienti.
In realtà la cosa che mi spaventa di più è il fatto di avere 100 download della stessa libreria probabilmente con versioni diverse.
Ho chiesto suggerimenti su Stack Overflow e mi è stato suggerito di utilizzare un repository locale di NuGet, dove scaricare i pacchetti che utilizzo in modo da ovviare al possibile problema delle versioni discordanti.
Vi do un paio di link per come fare:
- Come configurare un local repository di NuGet
- Utilizzare i local feeds secondo NuGet.org
- Installare NuGet.Server nella propria organizzazione
Queste soluzioni risolvono alcuni problemi, ma soprattutto le ultime due, che sono suggerite da NuGet, sono più adatte ad una organizzazione con molti sviluppatori, piuttosto che ad un singolo professionista. La prima invece è molto semplice e può essere facilmente implementata anche su un semplice PC.
Ovviamente, io, da buon dinosauro, guardando alla mia modalità di lavoro soprattutto per la parte tutorial, ho deciso di usare il solito approccio: Keep it Simple.
Potreste definirlo artigianale, non c’è problema, potete usare i reference diretti su NuGet, li citerò sempre, oppure potete usare la soluzione Local Repository e non guardare a quello che ho fatto io, la mia è solo un alternativa possibile.
Cosa ho fatto
Il mio scopo è quello di avere una sola versione delle librerie che scarico da NuGet per tutti i miei progetti, questo significa che se cambio la versione della libreria che uso, compilerò e aggiornerò (se vi fossero breaking changes) tutti i miei progetti. E’ una scelta da parte mia, che in 12 anni di .Net non mi sono mai pentita di aver fatto, anche se qualche volta ho dovuto ricompilare progetti antichi, ma i breaking changes sono stati davvero in numero molto limitato.
Ecco come ho fatto:
Ho creato una solution, che ho chiamato NuGetLibs che non contiene nulla, ho usato il template Class Libraries, per cui mi è stata creata una Class1.cs che lascio dove si trova.
Ho usato Manage NuGet Packages per aggiungere la libreria che mi interessava.
Una volta aggiunta, Extended.Wpf.Toolkit diviene parte della mia libreria “fake”.
La trovo infatti nei reference di progetto.
A questo punto, inserisco un comando che copia le DLL del progetto nella cartella dove copio tutte le librerie base di DotNetwork.
Compilando il progetto, troverò nella cartella C:\Dotnetwork che ho scelto per pubblicare tutte le mie librerie di uso comune, sia la libreria finta, che contiene Class1 che le librerie del Toolkit. Per utilizzarle, non dovrò fare altro che referenziare le librerie da questa cartella, senza dover fare un altro riferimento su NuGet.
Dalla mia libreria, inizio con un click destro e add reference.
Seleziono il Browse per andare a cercare la mia libreria.
Seleziono la cartella C:\Dotnetwork e seleziono la libreria del toolkit.
Dopo di ciò, la mia libreria ha il reference al Wpf.Toolkit e può usarne i componenti.
Qual’è il vantaggio di fare tutto questo?
- Un unico punto di entrata per le librerie esterne,
- un unica versione delle librerie esterne,
- la possibilità di aggiornarle in caso di nuove versioni con un aggiornamento della soluzione collegata a NuGet e una ricompilazione dei nostri progetti.
- Posso referenziare solo le Dll che uso invece che tutte quelle di un pacchetto come succede in questo caso.
Qual’è lo svantaggio?
- L’aggiornamento della libreria esterna deve essere effettuato manualmente. (Ma non so se è uno svantaggio)
- Se cambiamo versione, dovremo ricompilare e aggiornare tutti i nostri progetti.
Per quello che è il mio tipo di lavoro e il mio modo di lavorare, gli svantaggi sono accettabili. Chi legge potrebbe decidere diversamente, non cambia nulla dal punto di vista operativo, se utilizzate direttamente NuGet nei vostri progetti, o se decidete di utilizzare un repository locale per le librerie.
Potete scaricare il progetto per la gestione dei packages dal link qui indicato:
Per qualsiasi domanda, osservazione, commento, approfondimento, o per segnalare un errore, potete usare il link alla form di contatto in cima alla pagina.