2010-10-15 14 views
6

Tengo un complemento VS que está usando un BinaryFormatter para deserializar un objeto. Para resolver el tipo de este objeto, llama a Assembly.Load (objectTypeFullName) pero está activando una excepción porque Assembly.Load no puede encontrar el ensamblado en ninguno de los lugares en los que está realizando la búsqueda. El ensamblado dado es hermano del ensamblaje complementario, pero parece que Assembly.Load() no puede encontrarlo allí.¿Cómo determinar dónde Assembly.Load() busca ensamblajes?

Una posible solución sería determinar dónde Assembly.Load debería buscar ensamblajes.

¿Qué debo hacer?

PD: Estoy tratando de no colocar este ensamblaje en GAC porque tendré que actualizarlo cada vez que vuelva a compilar el ensamblaje.

Respuesta

4

Puede usar AppDomainSetup.PrivateBinPath para agregar rutas de búsqueda privadas adicionales. Esto se puede recuperar a través del AppDomain.SetupInformation.

Otra opción es suscribirse a AppDomain.AssemblyResolve para anular el comportamiento cuando no puede encontrar su ensamblaje.

+0

Gracias Reed. Algunas notas: aunque AppDomain.AppendPrivatePath está en desuso en favor de AppDomainSetup.PrivateBinPath, solo pude usar el primero. AppDomainSetup.PrivateBinPath permanece nulo después de que lo modifique. AppDomain.AppendPrivatePath me permite agregar cualquier ruta QUE ES UN NIÑO DE AppDomain.BaseDirectory, que en muchos casos es suficiente, no en el mío porque mi BaseDirectory es el directorio DevEnv. La otra solución, AppDomain.AssemblyResolve es lo suficientemente buena. Notas: El evento solo se invoca cuando .NET no puede resolver el ensamblaje por sí mismo. Si todos los controladores devuelven nulo, se lanza una excepción –

3

Si solo está tratando de determinar de dónde está tratando de cargar el dll el cargador de ensamblaje, le recomiendo que active los registros de fusión. Si lo hace, le permitirá obtener resultados que le mostrarán cada ruta que se verificó para la dll correspondiente.

Hay un MSDN article sobre cómo configurar los registros de fusión, y un artículo útil por Suzanne Cook sobre cómo depurar errores de carga. Si activa LogFailures y solo debe obtener resultados para ensamblajes que no se cargaron.

+0

Muy interesantes estos registros de fusión, estoy leyendo el artículo. Gracias. –

4

He aquí un fragmento de código que muestra cómo AssemblyResolve podría ser utilizado para resolver su montaje (según la respuesta de Reed Copey):

// register to listen to all assembly resolving attempts: 
AppDomain currentDomain = AppDomain.CurrentDomain; 
currentDomain.AssemblyResolve += new ResolveEventHandler(MyResolveEventHandler); 


// Check whether the desired assembly is already loaded 
private static Assembly MyResolveEventHandler(object sender, ResolveEventArgs args) { 
    string desiredAssmebly = args.Name; 
    if (desiredAssembly.Equals("NameUsedToLoadMyAssembly")){ 
     return Assembly.LoadFrom(myAssemblyPath); 
    } 

    return null; 
    } 

Además, tenga en cuenta que la página de MSDN para AssemblyResolve establece que:

A partir de la versión 4 de .NET Framework , la propiedad ResolveEventArgs.RequestingAssembly de devuelve el conjunto que solicitó la carga de ensamblaje que podría no se ha resuelto ...

Esto se puede utilizar si conoce la ubicación de su conjunto en relación con la del conjunto solicitante.

+0

Hershi, gracias +1. De hecho, su solución resultó ser la que yo usé, y terminé usando su fragmento. Marqué la respuesta de Reed como aceptada, ya que es más completa. Gracias de todos modos. –

Cuestiones relacionadas