web-dev-qa-db-fra.com

Qu'est-ce qui pourrait causer une exception System.TypeLoadException?

Je développe, avec VS2008 utilisant C #, une application pour Honeywell Dolphin 6100, un ordinateur portable doté d'un scanner de codes à barres utilisant Windows CE 5.0 comme le système d'exploitation.

Je souhaite ajouter une fonctionnalité permettant d'envoyer des fichiers du périphérique local au serveur distant. J'ai trouvé la bibliothèque " Tamir.SharpSSH " qui peut le garantir. J'ai testé le code sur une application console et sur une application Windows Forms normale et cela fonctionne parfaitement. Mais lorsque j'essaie d'utiliser le même code sur le périphérique winCE, je reçois une exception TypeLoadException et le message d'erreur suivant s'affiche:

 Impossible de charger le type 'Tamir.SharpSsh.SshTransferProtocolBase' depuis Assembly 'Tamir.SharpSSH, 
 Version = 1.1.1.13, Culture = neutre, PublicKeyToken = null' .

le code que j'utilise est comme ci-dessous:

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();

Quelqu'un a une idée à ce sujet? Je serai vraiment reconnaissant !!!

c#visual-studiosshwindows-cesmart-device
18
J.M.J

Cela pourrait être n'importe quel nombre de choses. Les causes probables sont:

  • L'assemblée est introuvable
  • Une assemblée dont dépend votre assemblée est introuvable
  • L'assemblée est trouvée mais le type n'y est pas
  • Le constructeur statique du type lève une exception

Le mieux est d’utiliser le visualiseur de journaux Fusion pour faciliter le diagnostic. La documentation est ici:

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

(FYI "Fusion" était le nom de code de l’équipe qui a conçu le système de chargement d’Assembly; il est quelque peu regrettable que le nom de code se retrouve dans le nom du fichier du produit livré. Il aurait dû s'appeler "AssemblyBindingLogViewer.exe" ou une telle chose.)

32
Eric Lippert

La réponse d'Eric Lippert décrit parfaitement la situation. 

Je veux juste ajouter une réponse rapide à propos d'un cas qui n'est généralement pas couvert par les pages d'aide concernant cette exception.

J'ai créé un projet de test rapide et sale pour certains éléments open source (Akka.Net, pour le nommer) et je nomme le projet lui-même "Akka". 

Il construit parfaitement, mais au démarrage, il lance une exception de type concernant une classe dans Akka.dll.

C'est simplement parce que mon exécutable (akka.exe) et la référence (akka.dll) ont le même nom. Cela m'a pris quelques minutes pour comprendre ceci (j'ai commencé par des choses telles que la copie locale, la plate-forme cible, la version exacte, etc.). 

C'est quelque chose de très bête mais pas forcément la première chose à laquelle vous allez penser (surtout que j'ai utilisé nuget pour les dépendances), alors j'ai pensé qu'il pourrait être intéressant de le partager: vous rencontrerez TypeLoadException si votre EXE et une dépendance ont le même nom.

19
AFract

Cela m'a presque rendu fou.

Je ne sais pas comment j'ai géré cela, mais pour une raison quelconque, j'avais une ancienne version de la DLL dans GAC. Essayez de chercher une vieille assemblée là-bas et retirez-la.

Bonne chance!

3
Hudson

Cela pourrait être dû à un certain nombre de choses, MSDN l'a dit comme:

TypeLoadException est levée lorsque le Common Language Runtime ne peut pas trouver l'assembly, le type dans l'assembly ou ne peut pas charger le type.

Il est donc clair qu’un type est introuvable, que l’assembly soit manquant ou qu’il existe un conflit entre les configurations d’exécution.

Parfois, le problème peut survenir parce que l'Assemblée que vous référencez est d'un type de plate-forme différent (32 bits/64 bits, etc.) de celui utilisé.

Je recommanderais d'attraper l'exception et de l'examiner plus en détail pour identifier les problèmes.

Suite à mes informations précédentes

J'ai parfois vu ce problème se produire car (pour une raison ou une autre) un assembly référencé ne peut pas être résolu, même s'il est référencé et chargé.

Je vois généralement cela lorsque les limites AppDomain sont impliquées.

Une des manières que j'ai trouvées qui résout parfois le problème (mais seulement si l'Assemblée est déjà dans AppDomain) est ce petit extrait de code:

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

Comme je l'ai dit, je vois ce problème lorsque AppDomains s'implique et cela semble résoudre le problème lorsque l'Assemblée est en effet déjà référencée et chargée. Je n'ai aucune idée pourquoi le framework ne parvient pas à résoudre la référence elle-même.

3
Clint

Vous pouvez extraire des fichiers journaux du chargeur du .NET Compact Framework en activant certains paramètres dans le registre. Les Power Toys pour .NET Compact Framework incluent un outil appelé NETCFLogging, qui définit les valeurs de registre pour vous.

Les valeurs de registre sont documentées ici:

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

1
Mike Dimmick

Assurez-vous que les noms (espaces de noms, noms de classe, etc.) sont ce qu’ils sont supposés être. J'ai eu cette erreur quand j'ai dû recommencer mon projet et j'ai copié le contenu de ma classe à partir d'un modèle et je n'ai pas réussi à changer le nom de la classe "Modèle de classe" en nom correct (il était censé correspondre au nom du projet) .

0
makesha.laun

Dans mon cas, le problème était que j'avais deux projets qui utilisaient les mêmes bibliothèques dans une solution. J'ai mis à jour les DLL uniquement dans le premier projet . Ainsi, lorsque j'ai construit la solution, vous devez ensuite projeter ses DLL de substitution à partir du premier projet (ordre de construction du projet). 

Exemple:

Solution: 

--MainProject

------ MyDll v5.3.2.0

--Prototype

------ MyDll v5.0.0.0

Problème disparu après la mise à jour des DLL dans le deuxième projet.

0
Mroczny Arturek