Ci sono stati molti post su questo argomento, ma non ho ancora trovato la soluzione "reale".Come eseguire la gestione delle dipendenze in Visual Studio/MSBuild
Come si fa a gestire il loro albero delle dipendenze (tempo e tempo di esecuzione compilazione) utilizzando i file di progetto MSBuild (cioè i file di progetto di Visual Studio tramite progetto e riferimenti ai file)?
È noto che i riferimenti di progetto da progetti figlio non verranno copiati in una directory bin dell'applicazione se non esiste un riferimento temporale di compilazione, anche se esiste una dipendenza di runtime e anche se copy-local = true. Quindi, qualsiasi componente liberamente accoppiato non verrà copiato.
L'hack per risolvere questo problema è includere la dipendenza nel progetto padre con copy-local = true. Tuttavia, questo distrugge fondamentalmente il tuo albero delle dipendenze perché non sai più dove si trova la dipendenza e alla fine, man mano che la tua app cresce e si trasforma, si finisce con una versione di inferno della DLL. Il tuo progetto padre finisce con 10 a 100 di DLL, la maggior parte delle quali sono dipendenze di runtime di DLL in progetti figlio.
Un altro trucco è quello di scrivere un file di profilo personalizzato e lo chiamano da ogni file di progetto: http://blog.alexyakunin.com/2009/09/making-msbuild-visual-studio-to.html. Ma sicuramente c'è un'opzione migliore. Questa è una cosa del pane e del burro. Gli sviluppatori Java non hanno mai a che fare con problemi così banali.
Da quello che ho potuto capire, il modo in cui Microsoft per risolvere questo problema è quello di registrare ogni dipendenza nel GAC per ogni macchina dev, collaudo e produzione. Ma questo è stupido e fastidioso. Non mi preoccuperò di dare questa opzione e la confutazione educata.
Evitare l'opzione GAC, come si potrebbe utilizzare MSBuild per gestire un albero delle dipendenze che include runtime solo le dipendenze? Come fa Microsoft? Sicuramente non eseguono file di target personalizzati come quello nel link sopra.
Spero che qualcuno di un ambiente aziendale .NET possa intensificare e offrire alcuni consigli reali su questo. Altrimenti dovrò riscrivere tutti i miei script di compilazione in NAnt (shudder).
Grazie Tutti.
UPDATE
In risposta ad alcuni commenti, il seguente è un esempio pratico della questione dal mio progetto attuale.
L'app è un progetto di applicazione Web che espone una suite di servizi WCF. Ha una DLL di dominio esterno che contiene le classi di servizio esterne e una DLL di dominio interno contenente POCO di servizi interni, oggetti dominio e DAO. Esiste una DLL di integrazione separata contenente le interfacce (DTO) per tutte le classi di dominio interne che ci consente di disaccoppiare completamente i domini esterni e interni. Il tutto è cablato con Spring.net. Spero che questo sia chiaro, fammi sapere se hai bisogno di ulteriori chiarimenti.
mio processo di generazione attuale è quella di utilizzare MSBuild per generare un pacchetto di distribuzione per l'applicazione web (in TFS Build). Quindi, mentre l'intera soluzione viene inizialmente creata, solo l'output dell'applicazione Web viene impacchettato. Pertanto, l'applicazione Web viene considerata come root delle dipendenze e mi aspetto che eventuali riferimenti secondari vagamente accoppiati vengano copiati su build se sono impostati su "copy-always = true".
Quindi l'applicazione Web contiene un riferimento alla DLL del dominio esterno che contiene un riferimento alla DLL del dominio interno che contiene molti riferimenti a librerie di terze parti e varie dipendenze indirette e liberamente accoppiate richieste dalle librerie di terze parti.
Il problema si verifica quando è presente una dipendenza di terze parti nella DLL del dominio interno, ad es. oracle.dataaccess che è richiesto da NHibernate in fase di runtime. Anche quando imposto 'copy-always = true' su queste DLL, esse non vengono copiate nel pacchetto dell'app Web. L'unico modo per includerli nel pacchetto consiste nell'aggiungere queste DLL ai riferimenti dell'applicazione Web. Non voglio farlo perché non ho più un albero di dipendenza significativo.
Spero che questo chiarisca la questione. Per favore fatemi sapere se qualcosa non è chiaro. È difficile descrivere questo genere di cose.
Se qualcuno ha anche un problema simile, parla e condividi la tua esperienza.
Sì Sono d'accordo con te che aggiungerli al GAC sarà inefficiente, ma ero solo curioso di sapere come NAnt ti aiuterà di più in questo caso? Inoltre, come nello sviluppo Java queste situazioni sarebbero gestite? Sto cercando altri indizi per poterti dare una risposta migliore ... Grazie –
Penso che voglia qualcosa di simile a Maven in Java. In effetti sto cercando anche qualcosa di simile. http://maven.apache.org/ –
Nella riflessione, penso che NAnt causerebbe più problemi. Aggiornerò il post originale con un esempio specifico del problema. –