2009-10-02 9 views
7

In fase di runtime, se un assembly di riferimento non viene caricato con ad es. "Convalida del nome valido non riuscita" (perché è firmata per il test), esiste un modo per fornire un assembly di sostituzione da un altro percorso che sia autenticato?Come fornire un assembly fallback al posto di quello che non può essere caricato?

Ho provato a sottoscrivere AppDomain.CurrentDomain.AssemblyResolve, ma non viene attivato, poiché l'assembly "cattivo" esiste tecnicamente, non può essere caricato.

Esiste un modo generico per fornire un assembly fallback quando non è possibile caricare un assieme?

+0

Puoi provare la cattura SecurityException quando si cerca di caricare l'assembly? –

+0

L'ho provato, ma non so cosa fare dopo ... Ho ancora bisogno di dire in qualche modo al caricatore di assiemi CLR di scegliere la giusta dipendenza quando carico il mio assieme ... –

+1

Che ne dici di provare a caricare l'assembly esplicitamente su avvio dell'applicazione e gestire l'eccezione. In qualche modo presumo, che il tuo assembly sia caricato automaticamente. – Rashack

risposta

1

Penso che si possa semplicemente chiamare assembly.LoadFrom per caricare il gruppo di propria scelta praticamente senza controlli di sicurezza. Questo ci piace molto all'inizio della nostra app in modo da poter gestire meglio la modifica della versione di altri assembly.

Anche guardare Assembly.LoadFrom Method (String, Evidence, Byte[], AssemblyHashAlgorithm) sembra come se fosse possibile controllare il passaggio nell'hash e nell'algoritmo di hash.

+0

Grazie Ho appena provato e che mi dà lo stesso "convalida nome sicuro non riuscita", anche se io punto al corretto montaggio: var = AssemblyName AssemblyName .GetAssemblyName (correctFileName); assemblaggio var = Assembly.Load (AssemblyName);. sto pensando questo è perché il correctFileName è al di fuori della cartella di applicazione Codebase Credo che mi limiterò a lasciarlo e andare un percorso diverso ... –

+0

con loadfrom si passa un percorso file ed è possibile caricare l'assembly da qualsiasi punto (praticamente). –

+0

Yup, LoadFrom sembravano farmi superare questo. Ho riscontrato altri problemi in seguito, quindi ho scartato l'intero approccio, ma sì, questo problema è stato risolto. Precaricare gli assembly anziché rispondere agli errori di caricamento. Grazie! –

1

Cosa provoca il tentativo di caricamento? IOW chiami Assembly.Load o questo è il risultato di un tentativo di risoluzione del tipo? Se è quest'ultimo si può provare a giocare con l'evento AppDomain TypeResolve, se il primo è possibile aggiungere ulteriore logica alla chiamata all'Assembly.Load.

Se si carica l'assieme manualmente, assicurarsi di caricarlo con Assembly.Load, non con Assembly.LoadFrom. Esistono sottili differenze nella risoluzione del tipo a seconda di quale assembly di contesto viene caricato in

+0

Non uso Assembly.Load: l'assembly in questione è collegato dal compilatore. Ogni volta che comincio a usare l'assembly, chiamo typeof (TypeInAssembly) .GetTypes(): carica il primo assembly e ricorsivamente il suo assembly referenziato senza segno. .. TypeResolve non venga sollevato sia :( Grazie comunque –

0

Sembra che quello che voglio sia impossibile. Ho deciso di fare un'altra strada. Dovremo modificare il sistema di compilazione per effettuare il collegamento condizionale ai binari firmati anziché ai binari firmati da test in fase di compilazione.

Grazie a tutti per i suggerimenti!

0

esiste un modo standard per trovare un assembly nel caso in cui l'applicazione non riesce a farlo:

// register on assembly resolve exception 
AppDomain.CurrentDomain.AssemblyResolve += ResolveEventHandler; 

// try to load the assembly yourself 
private static Assembly ResolveEventHandler(object sender, ResolveEventArgs args) 
{ 
    return Assembly.Load(some_location); 
} 
Problemi correlati