¿Qué podría estar causando una System.TypeLoadException?

Estoy desarrollando, con VS2008 usando C #, una aplicación para Honeywell Dolphin 6100, una computadora móvil con un escáner de código de barras que usa Windows CE 5.0 como sistema operativo.

Deseo agregar una funcionalidad que pueda enviar archivos desde el dispositivo local al servidor distante. Encontré el librairy ” Tamir.SharpSSH ” que puede garantizar esto. Probé el código en una aplicación de consola y en una aplicación de formularios de Windows normal y funciona perfectamente. Pero cuando traté de usar el mismo código en el dispositivo winCE, recibo una TypeLoadException y aparece el mensaje de error:

 No se pudo cargar el tipo 'Tamir.SharpSsh.SshTransferProtocolBase' del ensamblado 'Tamir.SharpSSH,   
 Versión = 1.1.1.13, Culture = neutral, PublicKeyToken = null '.

el código que uso es como a continuación:

SshTransferProtocolBase sshCp = new Scp(Tools.GlobalVarMeth.hostName, Tools.GlobalVarMeth.serverUserName); sshCp.Password = Tools.GlobalVarMeth.serverUserpassword; sshCp.Connect(); string localFile = Tools.GlobalVarMeth.applicationPath + "/" + fileName + ".csv"; string remoteFile = Tools.GlobalVarMeth.serverRemoteFilePath + "/" + fileName + ".csv"; sshCp.Put(localFile, remoteFile); sshCp.Close(); 

¿Alguien tiene alguna idea sobre esto? ¡Estaré realmente agradecido!

Podría ser cualquier cantidad de cosas. Las causas probables son:

  • El ensamblaje no se puede encontrar
  • No se puede encontrar un ensamblaje del que depende su ensamblaje
  • Se encuentra el ensamblaje pero el tipo no está en él
  • El constructor estático del tipo arroja una excepción

Su mejor opción es usar el visor de registro de Fusion para ayudar a diagnosticarlo. La documentación está aquí:

http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx

(FYI “Fusion” fue el nombre clave del equipo que diseñó el sistema de carga del ensamblaje, es algo desafortunado que el nombre del código terminara en el nombre del archivo del producto enviado. La cosa debería haberse llamado “AssemblyBindingLogViewer.exe” o algo así.)

La respuesta de Eric Lippert describe perfectamente la situación.

Solo deseo agregar una respuesta rápida sobre un caso que generalmente no está cubierto por las páginas de ayuda con respecto a esta excepción.

He creado un proyecto de prueba rápido y sucio para algunas cosas de código abierto (Akka.Net, por nombrarlo) y le doy el nombre del proyecto “Akka”.

Se construye perfectamente, pero al inicio lo arroja tipo cargar excepción con respecto a una clase en Akka.dll.

Esto es solo porque mi ejecutable (akka.exe) y la referencia (akka.dll) tienen el mismo nombre. Me tomó unos minutos darme cuenta de esto (empecé por cosas como copiar local, plataforma de destino, versión exacta … etc.).

Es algo muy tonto, pero no a la fuerza, lo primero que pensarás (especialmente porque utilicé nuget para dependencias), así que pensé que podría ser interesante compartirlo: encontrarás TypeLoadException si tu EXE y una dependencia tienen el mismo nombre.

Esto podría ser causado por cualquier cantidad de cosas, MSDN lo ha dicho como:

TypeLoadException se genera cuando el tiempo de ejecución del lenguaje común no puede encontrar el ensamblado, el tipo dentro del ensamblaje o no puede cargar el tipo.

Por lo tanto, está claro que no se puede encontrar un tipo, falta el ensamblaje, falta el tipo o hay un conflicto entre las configuraciones de tiempo de ejecución.

A veces, el problema puede surgir porque el ensamblado al que hace referencia es de un tipo de plataforma diferente (32 bits / 64 bits, etc.) del que está consumiendo.

Recomendaría capturar la excepción y examinarla con más detalle para identificar con qué está teniendo problemas.


Además de mi información previa

A veces he visto surgir este problema porque (por una razón u otra) un ensamblado al que se hace referencia no se puede resolver, aunque se haga referencia y se cargue.

Normalmente veo esto cuando los límites de AppDomain están involucrados.

Una forma que he encontrado que a veces resuelve el problema (pero solo si el ensamblado ya está en el dominio de la aplicación) es este pequeño fragmento de código:

 AppDomain.CurrentDomain.AsemblyResolve += (s, e) => { return AppDomain.CurrentDomain.GetAssemblies() .SingleOrDefault(asm => asm.FullName == e.Name); } 

Como dije, veo este problema cuando AppDomains se involucra y parece solucionarlo cuando el ensamblado ya está referenciado y cargado. No tengo idea de por qué el marco no puede resolver la referencia en sí.

Esto casi me vuelve loco …

No sé cómo logré esto, pero por alguna razón tenía una versión anterior de la DLL en GAC. Intenta buscar un ensamblaje antiguo allí y quítalo.

¡La mejor de las suertes!

Puede obtener los archivos de registro del cargador fuera de .NET Compact Framework habilitando algunas configuraciones en el registro. Power Toys para .NET Compact Framework incluye una herramienta llamada NETCFLogging, que establece los valores de registro para usted.

Los valores de registro están documentados aquí:

http://msdn.microsoft.com/en-us/library/ms229650(v=VS.90).aspx

En mi caso, el problema fue que tenía dos proyectos que usaban las mismas bibliotecas en una solución. Actualicé las DLL solo en el primer proyecto. Así que cuando construí una solución, el segundo proyecto reemplaza las DLL del primer proyecto (orden de comstackción del proyecto).

Ejemplo:

Solución:

–MainProject

—— MyDll v5.3.2.0

–Prototipo

—— MyDll v5.0.0.0

Problema desaparecido después de las DLL de actualización en el segundo proyecto.

Asegúrese de que los nombres (espacios de nombres, nombres de clase, etc.) sean lo que se supone que son. Recibí este error cuando tuve que empezar de nuevo en mi proyecto y copié el contenido de mi clase de una plantilla y no cambié el nombre de la clase de “Clase de plantilla” al nombre correcto (se suponía que coincidía con el nombre del proyecto) .