c# - ¿Qué podría estar causando una excepción System.TypeLoadException?

visual-studio ssh

Question

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 SO.

Quiero 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 normal de formularios de Windows y funciona perfectamente. Pero cuando intenté usar el mismo código en el dispositivo winCE, obtengo una excepción TypeLoadException y tengo el mensaje de error:

Could not load type ''Tamir.SharpSsh.SshTransferProtocolBase'' from assembly ''Tamir.SharpSSH, Version=1.1.1.13, Culture=neutral, PublicKeyToken=null''.

El código que estoy usando es el siguiente:

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é muy agradecido!

Answer 1

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 volver a empezar en mi proyecto y copié el contenido de mi clase de una plantilla y no pude cambiar el nombre de la clase de "Clase de plantilla" al nombre correcto (se suponía que coincidía con el nombre del proyecto) .

Answer 2

En mi caso, el problema era que tenía dos proyectos que usaban las mismas bibliotecas en una solución. He actualizado DLL solo en el primer proyecto. Así que cuando construí la solución, el segundo proyecto está anulando las DLL del primer proyecto (orden de compilación del proyecto).

Ejemplo:

Solución:

--Proyecto principal

------ MyDll v5.3.2.0

--Prototipo

------ MyDll v5.0.0.0

Problema ido después de actualizar DLL en el segundo proyecto.

Answer 3

Esto casi me vuelve loco ...

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

¡La mejor de las suertes!

Answer 4

Esto puede ser causado por cualquier número de cosas, MSDN lo dice como:

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

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

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

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

Más allá de mi información anterior

A veces he visto surgir este problema porque (por una razón u otra) un ensamblaje al que se hace referencia no se puede resolver realmente, a pesar de que está referenciado y cargado.

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

Una forma en que he encontrado que a veces resuelve el problema (pero solo si el ensamblaje ya está en el dominio de 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 esto parece resolverlo cuando el ensamblaje ya está referenciado y cargado. No tengo idea de por qué el marco no puede resolver la referencia en sí.

Answer 5

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

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

He creado un proyecto de prueba rápido y sucio para algunas cosas de código abierto (Akka.Net, para nombrarlo) y llamo al proyecto "Akka".

Se construye a la perfección, pero al iniciarse, lanza la excepción de carga de tipo con respecto a una clase en Akka.dll.

Esto se debe a que mi ejecutable (akka.exe) y la referencia (akka.dll) tienen el mismo nombre. Me tomó unos minutos darme cuenta de esto (comencé por cosas como copiar local, plataforma objetivo, versión exacta ... etc.).

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

Answer 6

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

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

Lo mejor 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 en código del equipo que diseñó el sistema de carga de ensamblajes; es algo desafortunado que el nombre en código terminó en el nombre de archivo del producto enviado. La cosa debería haberse llamado "AssemblyBindingLogViewer.exe" o algo así.)

Answer 7

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

Los valores de registro se documentan aquí:

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