Come devo fare riferimento agli assiemi di un'altra soluzione?

Question

Ho due scenari:

1. c'è un progetto quadro per l'azienda, e per tutti i progetti che ci accingiamo a utilizzare questo quadro.

2. Esiste un progetto Framework personalizzato che è specifico per un client e solo alcune persone della società avranno mai bisogno di utilizzare questa DLL.

Entrambi i framework sono memorizzati in soluzioni separate su TFS.

Come utilizzare i riferimenti per altri progetti? Devo inserire entrambi gli assembly su GAC o qualcosa del genere? Dovrei copiare manualmente il gruppo di uscita? Cosa è raccomandato, perché e come lo uso?

Answer 1

quadro personalizzato

copiare l'assembly di uscita manualmente per il progetto personalizzato a meno che non si può comprendere che è fonte direttamente nella soluzione.

Shared quadro

userei NuGet invece di GAC qualsiasi momento da quando si sbarazzarsi di eventuali problemi di controllo delle versioni o di dover creare un pacchetto di installazione separato per il quadro (dal momento che GAC)

è facile per creare un server privato di nuget. Basta creare un nuovo progetto MVC3 e installare un pacchetto server nuget: http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

Answer 2

Aggiungere l'assieme di riferimento a una cartella di libreria negli altri progetti e aggiornarlo manualmente. Considerare l'utilizzo del proprio feed NuGet se aggiornato di frequente.

Answer 3

È necessario condividere gli assembly installandoli nella cache di assembly globale solo quando è necessario. Come linea guida generale, mantenere le dipendenze di assembly private e individuare gli assembly nella directory dell'applicazione a meno che la condivisione di un assembly non sia richiesta esplicitamente. Inoltre, non è necessario installare gli assembly nella cache di assembly globale per renderli accessibili all'interoperabilità COM o codice non gestito

Vorrei mettere i primi ddl del framework nel GAC a causa di quanto sopra.

avrei messo il secondo quadro in una cartella progettata sotto i TFS chiamati da esempio "Library", dove potrete aggiungere un riferimento da (Tutta la tua squadra deve avere la stessa struttura di cartelle per evitare riferimenti mancanti)

Answer 4

Così # 2 il progetto quadro personalizzato è la stessa cosa del numero 1, ma personalizzato per un particolare cliente?

Sarebbe sensato rendere il codice sorgente Framework personalizzato un ramo del normale codice sorgente Framework, invece di mantenerlo come una soluzione separata separata? Suppongo che dipenderà da quanto ampie sono le differenze.

Come ho visto, il vantaggio di renderlo un ramo è che si dovrebbe essere in grado di unire più facilmente le modifiche tra i due rami. Immagina che una correzione di bug o una nuova funzionalità sia fatta in # 1 e che debba essere applicata anche a # 2; TFS dovrebbe essere in grado di renderlo più semplice, a condizione che TFS sia consapevole del fatto che # 2 è solo un ramo di # 1.

In ogni caso, per arrivare al punto della domanda, il mio pensiero è che gli altri progetti dovrebbero fare riferimento agli assembly di output di questi progetti.

Vorrei copiare gli assembly Framework in una cartella nella cartella della soluzione degli altri progetti. Io generalmente chiamo il mio "Dipendenze", ma in realtà non importa. I tuoi progetti aggiungono un riferimento a quei file di assembly. Suppongo che gli assembly Framework personalizzati abbiano lo stesso nome dei normali assembly Framework, quindi è possibile scambiare facilmente quei file in base alle esigenze (o creare rami separati dei progetti che utilizzano il framework personalizzato).

Scorrii l'inserimento degli assembly nel GAC, perché è facile inciampare durante lo sviluppo se si dimentica di disinstallare una versione precedente dell'assembly dal GAC.

Answer 5

Mi sembra un classico riferimento al progetto rispetto al processo decisionale di riferimento binario. Lascia il GAC fuori da questo.

In topologie che ricorda il vostro requisito usiamo qualcosa di simile:

 
|___$/3rdParty/ 
|  |__BaseFramework.dll 
|  |__CustomFramework.dll 
|  |__log4net.dll 
|  |__WPFToolkit.dll 
| 
|___$/Sources/ProjectName/NormalProject.sln 
|       | 
|       |__[Binary Reference] "../../3rdParty/BaseFramework.dll" 
|       |__[Project Reference] 
|       |__[Project Reference] 
| 
|___$/Sources/Common/BaseFramework.sln 
|     | 
|     |__[Project Reference] 
|     |__[Project Reference] 
|     |__[Project Reference] 
|     |__[Project Reference] 
| 
|___$/Sources/Custom/Acme/AcmeProject.sln 
|       | 
|       |__[Binary Reference] "../../../3rd-party/CustomFramework.dll" 
|       |__[Project Reference] 
|       |__[Project Reference] 
| 
|___$/Sources/Custom/CustomFramework.sln 
        | 
        |__[Project Reference] 
        |__[Project Reference] 
        |__[Project Reference] 
        |__[Project Reference]