Copia ricorsiva di Visual Studio locale

Question

Duplicato - questa domanda esatta è stata richiesta here - l'unica soluzione sembra essere l'evento post-build.

in Visual Studio 2008, ho i seguenti progetti:

• A - B riferimenti

• B - riferimenti lib.dll

Quando B è costruito, Lib .dll appare in B/bin/Debug. (questo è ok)

Quando A è compilato, B.dll appare in A/bin/Debug, ma Lib.dll NON appare in A/bin/Debug.

Non sarebbe un comportamento logico copiare anche tutte le dipendenze di B nel percorso di output di A, poiché B avrà bisogno di questi assembly in fase di esecuzione?

Tutti i riferimenti hanno copylocal = true.

---

(ora devo riferire dipendenze tutte di B da A a mano, è corretto? Potrei anche utilizzare un passaggio di generazione personalizzata immagino. In ogni caso, non questo comportamento avere vantaggi/senso?)

Answer 1

Questo funziona solo se l'assembly è effettivamente referenziato da .dll. Ad esempio, se si dispone di LibInterface.dll e LibImplementation.dll e il codice in A fa riferimento solo alle classi in LibInterface.dll, non è possibile ottenere LibImplentation.dll nell'output per B (cleanly).

Questo vale anche per qualsiasi file arbitrario, ovvero se si ha Randon.myFile correlato al progetto A, questa è la procedura desiderata: 1. Aggiungi come copia locale o crea evento al progetto A (quindi diventa in alto per il progetto A) 2. Nel Progetto B, impostare "copia locale" sul progetto A rif. 3. Dovresti quindi ottenere tutto nell'output del progetto A nel progetto B (incluso il tuo file) - ma non lo fai.

Potrebbe esserci qualche altra opzione - "Copia locale - tutto" o qualcosa del genere. Ciò aiuterebbe VS a supportare tecniche di IOC e astrazioni pulite.

Answer 2

Ho eseguito la stessa procedura molte volte e non è necessario riorientare manualmente gli assiemi. Un modo semplice per verificare questo è:

1. riferimento B in A
2. Crea un'istanza di un oggetto da B a A.
3. compilazione.

Se la compilazione viene completata correttamente, viene fatto riferimento a OK.

Answer 3

Se Lib.dll è una DLL di interoperabilità, la relativa DLL sottostante non verrà copiata. A parte questo, direi che c'è probabilmente un errore dell'operatore perché non è assolutamente necessario fare riferimento manualmente agli assembly gestiti dipendenti.