2014-10-15 13 views
5

Ho un assembly interamente riempito con classi che implementano interfacce in un altro assembly. Ad esempio:Assemblaggio in fase di ottimizzazione fuori produzione

Main Assembly (Reference to both assemblies) 

Shared Assembly 
-----IModule 

Class Assembly (Reference to shared assembly) 
-----unknownType : IModule 
-----unknownType2 : IModule 

L'assieme Principale non ha alcun riferimento diretto a nessuno dei tipi nell'assieme Classe. Sto cercando per i tipi in questo modo:

// Load all referenced assemblies: 
Assembly.GetExecutingAssembly().GetReferencedAssemblies() 
    .Except(AppDomain.CurrentDomain.GetAssemblies().Select(a => a.GetName())) 
    .Distinct() 
    .ToList() 
    .ForEach(act => Assembly.Load(act)); 

// Find all instances of IModule in loaded assemblies: 
var modules = from asm in AppDomain.CurrentDomain.GetAssemblies() 
    from provider in asm.GetTypes() 
    where typeof(IModule).IsAssignableFrom(provider) 
    ...instantiate type etc... 

Se ho un riferimento a solo un tipo arbitrario nell'Assemblea classe, poi si presenta in GetReferencedAssemblies, viene caricato e restituito correttamente - ma non appena i rimuove il riferimento al tipo, non viene trasferito alla directory di build o appare come un assembly di riferimento che causa il fallimento del caricamento.

Esiste un modo per forzare VS a includere questo assembly nella directory di output? L'applicazione principale non dovrebbe avere alcuna conoscenza di nessuno dei tipi all'interno dell'assembly di classe.

+3

Mi ricordo di avere un problema simile e l'unica soluzione che ho trovato è stata l'aggiunta di una chiamata fittizia agli assembly di riferimento nel progetto ... –

+0

@KevinD: Poiché l'assembly principale non dovrebbe sapere cosa succede nel assembly di classe, non posso realisticamente aggiungere un riferimento fittizio a meno che non preveda che un assembly type in class sia stato creato appositamente per quello scopo. Il problema è che l'esempio qui è troppo semplificato e così facendo aggiungerebbe complicazioni e fango inutili al design. – caesay

+1

Si tratta di un problema specifico della soluzione o è possibile fornire passaggi per riprodurlo in un contesto arbitrario? – Grx70

risposta

-1

Penso di avere il tuo problema, ma puoi chiarire la tua domanda? Stai aspettando un assembly che hai aggiunto come riferimento al tuo progetto da copiare nella tua cartella di output con la tua applicazione? Come hai aggiunto il riferimento? È un file .dll o .exe che hai sfogliato in una finestra di dialogo, oppure è un assembly COM o GAC che hai selezionato da un elenco nella finestra di dialogo Aggiungi riferimenti?

Se è stato visualizzato e non si trova nella directory GAC, è previsto questo tipo di ottimizzazione. Seleziona il tuo riferimento in Solution Explorer e assicurati che "Copia locale" nella finestra delle proprietà sia impostato su true. Potresti provare a cambiare questa impostazione, anche se lo è. Il tuo file .vsproj potrebbe semplicemente essere ricostruito per includere il riferimento.

Se si sta tentando di fare riferimento a una dll da un nome di file memorizzato in una stringa o selezionato in fase di runtime, Visual Studio non avrà modo di sapere che l'applicazione lo sta utilizzando, tuttavia lo copierà sul proprio cartella di destinazione. Tuttavia, non dovrebbe essere troppo difficile farlo con File.Copy, se si ha il percorso del file .dll.

+0

Chiaramente le persone che hanno commentato il post originale hanno una migliore comprensione della domanda e hanno fornito risposte migliori. Mi aspetto un assembly che viene aggiunto come dipendenza di progetto (riferimento) per essere copiato nella directory di output anche se non ci sono usi diretti del codice. Visual Studio vedrà che nessun tipo viene utilizzato direttamente e non copierà l'assembly di riferimento nella directory di output. La domanda riguarda come prevenire questo comportamento di ottimizzazione. – caesay

+0

Ah, grazie per aver chiarito. Non c'era un punto interrogativo nella tua domanda, quindi mi stavo dando una pugnalata a quale delle tue affermazioni volevi una risposta. Hai provato ad aprire il file .csproj nella directory della soluzione e controllarne le dipendenze? Avevo problemi analoghi con le risorse di immagini e icone non incluse in VS 2008 e la soluzione era quindi quella di rimuovere una riga che impediva esplicitamente la lettura del riferimento, quindi l'impostazione Copia locale non veniva letta. Per curiosità, perché vuoi solo fare riferimento all'assembly dinamicamente, e non per nome nel codice? –

Problemi correlati