2011-02-09 17 views
7

Ho una soluzione con più progetti con tutte le DLL di output (tranne l'applicazione principale, ovviamente). Copia locale è impostato su true per tutti i riferimenti e tutto è perfetto e dandy con dll nella stessa directory dell'exe.Inserimento di riferimenti del progetto C# in una sottocartella

Il mio problema è che questo è brutto. Mi piacerebbe mettere tutte le DLL in una sottocartella (in realtà due sottocartelle in basso per essere precisi). Come posso fare questo in Visual Studio 2008?

Ho trovato alcune domande che sembrano simili ma non ho trovato la risposta semplice che so che deve esistere.

MODIFICA: per maggiore chiarezza, desidero sapere come fare in modo che il caricatore di assioli assegni riferimenti da qualche parte oltre alla directory operativa. Gli utenti interagiranno con alcuni degli altri file nella directory, e meno spazio ci sarà per loro e meglio sarà.

EDIT 2: Voglio anche evitare l'uso del GAC. L'applicazione deve essere autonoma.

+0

Ma come verranno caricati? Dovrai caricare ogni DLL manualmente, che fa schifo. E se l'hai fatto, non fai riferimento ai progetti con il freddo: non puoi semplicemente usare i tipi in essi contenuti. Overkill totale ed esplosione cerebrale. –

+0

Idealmente c'è un modo in VS per far sì che l'applicazione cerchi tutte le dipendenze da qualche parte oltre alla directory operativa. Non riesco a immaginare che sia così difficile. – daedalus28

risposta

2

O AssemblyResolve

public static class AssemblyResolver { 
    static AssemblyResolver() { 
     AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(delegate(object sender, ResolveEventArgs args) { 
      return Assembly.LoadFrom(...); 
     }); 
    } 
} 
+0

ah in realtà questo è il modo non deprecato di farlo :) – daedalus28

0

Non è possibile inserire tali riferimenti in una sottocartella. Dal momento che non saranno "visti" dal tempo di esecuzione della tua applicazione.

Il primo posto per inserirli è nella directory di debug, quindi nella Global Assembly Cache (aka GAC). Nota che ciò che vedi nella scheda (.Net) nella finestra di dialogo Add Reference sono in realtà i riferimenti nella directory GAC.

Nota: Se si utilizza TFS come un controllo origine back-end, prendere atto che il riferimento non vengono copiati nel repository di controllo di origine quando si esegue un check-in, piuttosto è necessario copiare manualmente.

4

Hai provato lo spazio dei nomi AppDomain?

AppDomain.CurrentDomain.AppendPrivatePath

http://www.vcskicks.com/csharp_assembly.php

+0

Questo ha funzionato magnificamente !!! – daedalus28

+0

Unico problema: Visual Studio avverte che è deprecato. Qualche consiglio sull'uso della nuova alternativa? Così com'è, l'applicazione sta funzionando bene – daedalus28

+0

PrivateBinPath? – djeeg

0

Ho appena pubblicare un articolo che spiega tutto questo con i dettagli. Partitioning Your Code Base Through .NET Assemblies and Visual Studio Project

Qui ci sono le linee guida risultanti dell'articolo:

  • ridurre drasticamente il numero di assemblee di base di codice.
  • Creare un nuovo assieme solo quando ciò è giustificato da un requisito specifico per la separazione fisica.
  • In un progetto di Visual Studio, utilizzare "riferimento per assembly" anziché "riferimento per progetto Visual Studio".
  • Non utilizzare mai l'opzione di riferimento di Visual Studio 'Copia locale = True'.
  • Inserire tutte le soluzioni VS e creare file .bat di azione in una directory $ rootDir $.
  • Compilare tutti gli assembly nelle directory: $ rootDir $ \ bin \ Debug e $ rootDir $ \ bin \ Release
  • Utilizzare la directory $ rootDir $ \ bin per ospitare gli assembly dei test.
1

Utilizzare l'app.config <probing> element per istruire .NET Runtime a cercare nelle sottocartelle per individuare ulteriori assembly. Vedi here.

Problemi correlati