La copia di una libreria di classi C # da una soluzione all'altra è l'unico modo per "condividere" quella libreria?

1

Un principio utile nella programmazione del computer è DRY (Do not Repeat Yourself). Sto cercando di seguire questa regola mentre sto rifattorizzando un grande progetto .NET Framework MVC suddividendolo in soluzioni separate.

Un problema che non riesco ancora a risolvere in mia soddisfazione riguarda un set di librerie C # (funzioni statiche, sostituzioni degli attributi di autorizzazione e altre) che devono essere identiche in ogni soluzione. Queste soluzioni vengono inviate al controllo del codice sorgente TFS, il che significa che i progetti collegati all'esterno della soluzione non verranno copiati sul controllo del codice sorgente. In altre parole, tutti i progetti devono essere contenuti all'interno della soluzione.

Questa immagine è un'illustrazione (molto semplificata) di ciò che sto cercando di descrivere. La mia intenzione è quella di avere la "copia master" per la soluzione top "C # .NET Framework Solution". Le altre soluzioni si basano su quelle stesse librerie. Mentre posso "collegarmi" a quelle soluzioni, quell'approccio funziona solo sul PC in cui queste soluzioni sono state create. I progetti collegati all'esterno della soluzione non possono essere spinti (nella mia esperienza) al controllo del codice sorgente.

L'approcciochestousando-chefunzionacomeprevisto-èdimantenerelamia"copia master" delle librerie di classi C # in una soluzione specifica. Ho copiato manualmente i progetti specifici della libreria di classi C # su ciascuna delle soluzioni che ne hanno bisogno. La cosa buona è che poiché il progetto "copiato" esiste nella soluzione, la soluzione può essere trasferita al controllo del codice sorgente nel modo desiderato. La cosa brutta è che questa è una "copia".

La mia unica domanda è questa: c'è un modo per avere il meglio di entrambi i mondi, in cui il progetto di libreria C # esiste nella soluzione, ma se apporto una modifica alla "copia master" tutte le "copie" nel altre soluzioni sono sincronizzate? Perché dovrei volerlo? Immagina se il codice cambia in una o più di quelle librerie e io (o il mio successore) dimentico di apportare tali cambiamenti in tutte quelle altre soluzioni? Cosa succede se commetto un errore in una o più copie?

La mia tecnica attuale è l'unica opzione che ho, o c'è un modo diverso per non rompere il principio di DRY?

    
posta RandomHandle 13.03.2018 - 18:07
fonte

2 risposte

12

La risposta più breve di sempre: pubblica la libreria riutilizzabile con le dipendenze richieste come pacchetto NuGet e installala ovunque sia necessario. Ti aiuterà anche nella versione.

Se la tua libreria di classi è .NET Framework, convertirla in .NET Standard risolverà molti problemi legati alla pubblicazione come pacchetto NuGet. Visual Studio 2017 rende molto facile farlo , ma solo se è lo standard .NET .

Per servire i pacchetti NuGet, ci sono alcune opzioni:

  • Copia il file .nupkg in un percorso di cartella condivisa. In Visual Studio, puoi configurare NuGet per leggere dal percorso della cartella Tools > Options > NuGet Packge Manager > Package Sources .
  • Segui le istruzioni su Hosting dei tuoi feed NuGet .
risposta data 13.03.2018 - 18:21
fonte
3

Se non utilizzi NuGet, crea una DLL di utilità comune e inseriscila in una cartella condivisa. Ad esempio, abbiamo una libreria DBUtils.dll di metodi DB comunemente usati che possiamo aggiungere come riferimento. Funziona alla grande per noi.

    
risposta data 13.03.2018 - 18:26
fonte

Leggi altre domande sui tag