Come avere più copie di origine di una dipendenza in un progetto g # C?

Question

Come avere più copie di origine di una dipendenza in un progetto g # C?

#1 da (10 voti)

4

Nella nostra azienda, sviluppiamo software di sistema informativo in C # .NET, che ha un'architettura client-server-modulo. Il progetto del modulo non dipende direttamente dal progetto server / client, ma solo dalle parti condivise. Quindi la struttura dei progetti core ha questo aspetto con le loro dipendenze:

server dipende da
- libreria condivisa dal server
- libreria comune
client dipende da
- libreria condivisa dal client
- libreria comune

E la struttura del modulo si presenta così:

modulo dipende da
- libreria condivisa dal server
- libreria condivisa dal client
- libreria comune

Usiamo Git e le dipendenze sono messe in atto usando i sottomoduli. Ma questo porta a "submodule hell": in un progetto, che contiene solo client e server puri, abbiamo già alcune librerie ( common-shared ) due volte. Quindi svilupparli è difficile, perché possiamo cambiare solo una "copia" in un momento e questo porta all'incompatibilità della versione, quando eseguiamo insieme client e server.

I moduli

lo rendono ancora più complicato e inutilizzabile, perché moltiplicano le copie delle librerie. Quando alcuni moduli vengono creati con una versione errata della libreria, possono portare a incompatibilità con client e server.

Una soluzione menzionata consiste nell'impostare i progetti in modo che dipendano dalle librerie al livello superiore dell'albero delle directory, ma penso che sia un equivoco. Rende anche impossibile costruire repository usando l'errore di configurazione.

La soluzione

Second sarebbe un monorepo, ma questo elimina la possibilità di tenere traccia dei problemi nella nostra istanza GitLab separatamente, eccetera ...

La soluzione

Terzo sta forse utilizzando NuGet, ma ciò rende i progetti di libreria non sviluppabili (dovremmo scrivere alcuni "progetti di test" per svilupparli separatamente).

Qual è la soluzione ottimale per questo codebase?

Grazie mille!

git c# .net dependencies submodules

posta David Indra 24.09.2018 - 10:18

fonte

1 risposta

Leggi altre domande sui tag git c# .net dependencies submodules

Concetti: test del livello API Come posso organizzare 3 ingegneri del software per lavorare insieme a 2 clienti?

score 10 · Answer 1

Ho sempre evitato questo problema usando Nuget. Se stai sviluppando .net è il gestore di pacchetti "standard" e funziona molto bene.

Il lato negativo, se presente, è che le tue dipendenze sono ora dll binari piuttosto che codice sorgente, che puoi eseguire il debug e modificare mentre vai.

Questo impone alcune restrizioni alle tue pratiche lavorative quotidiane, devi aprire più copie di Visual Studio ecc. Anche se ci sono molte soluzioni alternative a problemi comuni che, a mio avviso, possono rendere la tua vita altrettanto facile che avere tutto in un'unica soluzione.

Tuttavia! Vorrei che strongmente sostenga che mantenere queste dipendenze separate e consumando solo l'output binario, ti costringa a pratiche migliori.

Test unitari. Poiché non puoi semplicemente modificare il codice quando stai scrivendo il progetto dipendente, sei costretto a essere sicuro che la tua libreria funzioni correttamente nel suo progetto.
Versioning. Le librerie di Nuget hanno bisogno di versioni. Ogni libreria ha la sua versione che può essere chiaramente vista.
CI. I requisiti di pubblicazione / versioning ti spingono verso build automatizzati sui build server
Con test unitari e versioning in atto, diventa evidente che l'ambito dei progetti dovrebbe essere limitato a aree funzionali reali. Non più 'Common-shared' che ottiene una nuova versione ogni ora anche se solo un piccolo bit è cambiato
Librerie complete e complete. Con il codice suddiviso in ambiti e con i propri test di unità, è possibile terminarne alcuni. Il tuo non aggiustare costantemente una dipendenza solo per rendere la vita leggermente più semplice in alcune app che la consumano, rompendone altre dieci che non conoscevi.

L'argomentazione di gran lunga più strong per questo approccio, tuttavia, è che tutti gli altri lo stanno facendo. Non ti preoccupare di non essere in grado di eseguire il debug di NewtonSoft.Json o System.Configuration, devi solo consumare la DLL e andare avanti con la tua vita.

Dovresti sforzarti di rendere le tue librerie facili da usare e affidabili quanto quelle pubblicate che usi ogni giorno.