Erreur MissingMemberException non comprise

Version imprimable

Bonsoir à tous,
depuis quelque semaine je me trouve confronté à une erreur qui se produit uniquement sur certain poste de mon entreprise.
Bien sur impossible de reproduire l'erreur sur mon poste :(

Voici l'erreur :

Citation:

System.MissingMemberException: Aucun membre par défaut
trouvé pour le type 'String'.
at Microsoft.VisualBasic.CompilerServices.LateBinding.LateIndexGet(Object o, Object[] args, String[] paramnames)

L'erreur arrive dans une fonction de remplissage d'une dataRow via des propriété ex :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Public Property pD_NUMERO_LOCAL() As String Get If IsDBNull(myRow("NUMLOC")) Then Return "" Return myRow("NUMLOC") End Get Set(ByVal value As String) If value.length > 3 Then Throw New ArgumentException("Maximum 3 charactère.", "NUMERO_LOCAL") If Not IsDBNull(myRow("NUMLOC")) Then If value = myRow("NUMLOC") Then Exit Property End If myRow("NUMLOC") = value End Set End Property
J'ai bien sur fait des recherches sur le net et j'ai trouvé sur msdn :

Citation:

A MissingMemberException exception is thrown when there is an attempt to dynamically access a class member that does not exist.
Associated Tips

If a member in a class library has been removed or renamed, recompile any assemblies that reference that library.

This exception is typically thrown when a field or method is deleted or renamed in one assembly, and the change is not reflected in a second assembly that is trying to access the missing member.
If you are attempting to access members on a late-bound object variable, make sure it is declared Public.

Protected , Friend, and Private variables cannot be late-bound in Visual Basic.

J'ai donc essayé de recompiler les différentes DLL qui sont dans le projet et de recompiler après le projet mais sans succès ce qui me semble logique vu que je n'utilise pas de fonction de ces dll lors du remplissage de la datarow

j'ai été voir du coté de
Microsoft.VisualBasic.CompilerServices.LateBinding.LateIndexGet
qui se trouve être une class du compilateur :

Citation:

Envoyé par msdn

Cette API prend en charge l'infrastructure .NET Framework et n'est pas destinée à être utilisée directement à partir de votre code.

Cette classe a été déconseillée depuis Visual Basic 2005.

Notes

Cette classe prend en charge le compilateur Visual Basic et n'est pas destinée à être directement utilisée à partir de votre code.

Donc ce n'est pas une piste non plus.

Maintenant je ne sais plus où chercher :(
J'espère donc trouver réponse ici comme bon nombre de fois :ccool:

09/12/2010, 00h55
tomlev

Déjà, commence par ne pas utiliser le late binding (ou liaison tardive, va voir cette page si tu ne sais pas ce que c'est) quand tu peux t'en passer. Déclare toujours explicitement les types des variables, pour que tout les appels puissent être résolus dès la compilation.

Le moyen le plus radical d'éviter d'utiliser accidentellement le late binding, c'est de configurer le projet pour que tous les late bindings soient considérés comme une erreur de compilation (options du projet, onglet Compilation, configuration des avertissements, et règle la notification du late binding sur "Erreur"). Mais ne fais pas ça si tu utilises des objets COM (interop Office par exemple), car dans ces cas là le late binding est nécessaire...

Concernant ton problème : comment est déclaré myRow ? Je soupçonne qu'il est déclaré comme étant de type Object, ou pas de type du tout ? A vue de nez, je suppose qu'il s'agit en fait d'un DataRow, mais le compilateur ne le sait pas, il utilise donc le late binding pour accéder à l'indexeur (le truc qui te permet d'écrire myRow("NomDuChamp")). C'est donc à l'exécution qu'il va voir s'il y a ou non un indexeur sur l'objet. Si par hasard, tu affectes à myRow un objet qui n'est pas un DataRow (ou du moins, qui n'a pas d'indexeur), ça va péter à l'exécution.

Si tu déclares explicitement le type de myRow comme étant DataRow, le compilateur pourra vérifier l'utilisation que tu en fais : l'accès à l'indexeur sera résolu à la compilation. De plus, si tu affectes à myRow autre chose qu'un DataRow, tu auras une erreur de compilation, ce qui vaut nettement mieux qu'une erreur à l'exécution, puisque tu peux tout de suite la repérer et la corriger.
09/12/2010, 08h03
sinople

Me semble que ce genre d'erreur peut aussi arriver s'il ne reconnait pas l'index textuel dans ton row.

Essaye de le remplacer par l'index numérique ou de changer l'index textuel.
09/12/2010, 10h03
tomlev

Citation:

Envoyé par sinople

Me semble que ce genre d'erreur peut aussi arriver s'il ne reconnait pas l'index textuel dans ton row.

Non, dans ce cas c'est une ArgumentException, pas une MissingMemberException (cf. MSDN)
09/12/2010, 11h12
sinople

Lors d'un changement datamember sur certains objet ce problème peut quand même apparaitre il me semble.

Typiquement je met un dataset en datasource et je met une jolie table appellée "date" (Ok je cherche les emmerdes mais c'est le but) en datamember ça balance cette erreur il me semble.

Parce que derrière il renomme "date" en "_date". Mais c'est vrai que à priori c'est pas la même situation.
09/12/2010, 23h31
Sankasssss

Bonsoir et merci à vous pour vos réponses :ccool:

Citation:

Envoyé par sinople

Me semble que ce genre d'erreur peut aussi arriver s'il ne reconnait pas l'index textuel dans ton row.

Essaye de le remplacer par l'index numérique ou de changer l'index textuel.

+

Citation:

Envoyé par sinople

Lors d'un changement datamember sur certains objet ce problème peut quand même apparaitre il me semble.

Typiquement je met un dataset en datasource et je met une jolie table appellée "date" (Ok je cherche les emmerdes mais c'est le but) en datamember ça balance cette erreur il me semble.

Parce que derrière il renomme "date" en "_date". Mais c'est vrai que à priori c'est pas la même situation.

Je ne pense pas que se soit le problème vu que cela fonctionne sur mon poste. Si j'avais une erreur dans le nom d'un champs ou d'une table il le ferait sur tout les postes je pense, de plus quand j'ai ce type de problème c'est ArgumentException qui est levé (pour le nom des colonnes du moins ;))

Citation:

Envoyé par tomlev

Le moyen le plus radical d'éviter d'utiliser accidentellement le late binding, c'est de configurer le projet pour que tous les late bindings soient considérés comme une erreur de compilation (options du projet, onglet Compilation, configuration des avertissements, et règle la notification du late binding sur "Erreur"). Mais ne fais pas ça si tu utilises des objets COM (interop Office par exemple), car dans ces cas là le late binding est nécessaire...

J'ai de la chance, dans ce projet je ne pilote aucun objets COM je vais donc configuré le projet pour considérer le late binding comme erreur.

Citation:

Envoyé par tomlev

Concernant ton problème : comment est déclaré myRow ? Je soupçonne qu'il est déclaré comme étant de type Object, ou pas de type du tout ? A vue de nez, je suppose qu'il s'agit en fait d'un DataRow, mais le compilateur ne le sait pas, il utilise donc le late binding pour accéder à l'indexeur (le truc qui te permet d'écrire myRow("NomDuChamp")). C'est donc à l'exécution qu'il va voir s'il y a ou non un indexeur sur l'objet. Si par hasard, tu affectes à myRow un objet qui n'est pas un DataRow (ou du moins, qui n'a pas d'indexeur), ça va péter à l'exécution.

Si tu déclares explicitement le type de myRow comme étant DataRow, le compilateur pourra vérifier l'utilisation que tu en fais : l'accès à l'indexeur sera résolu à la compilation. De plus, si tu affectes à myRow autre chose qu'un DataRow, tu auras une erreur de compilation, ce qui vaut nettement mieux qu'une erreur à l'exécution, puisque tu peux tout de suite la repérer et la corriger.

Je vais vérifier ca demain mais je pense vraiment que j'ai déclarer myRow en DataRow mais on ne sais jamais ;)

Ce qui m'étonne le plus c'est que le projet tourne sans problème sur pas mal de poste (dont le mien) et ce dans des conditions d'utilisation identique (Utilisateur du poste qui pose problème à mes cotés pour les même manipulations que celle qui pose problème et sur mon poste ca passe) :(

Je vous tien au courant demain après les tests de ces quelques conseilles.
Bonne nuit.
10/12/2010, 00h57
tomlev

Citation:

Envoyé par Sankasssss

Je vais vérifier ca demain mais je pense vraiment que j'ai déclarer myRow en DataRow mais on ne sais jamais ;)

Ben par rapport au code que tu montres, je ne vois aucune autre possibilité... une MissingMemberException correspond à un accès dynamique à un membre d'une classe, et la seule raison pour laquelle il ferait ça serait que le type de myRow ne soit pas déclaré explicitement
13/12/2010, 23h26
Sankasssss

Bonsoir,
Après vérification myRow est bien de type datarow :(

En regardant de plus près l'erreur :

Citation:

System.MissingMemberException: Aucun membre par défaut
trouvé pour le type 'String'.
at Microsoft.VisualBasic.CompilerServices.LateBinding.LateIndexGet(Object o, Object[] args, String[] paramnames)

Je trouve bizarre que c'est pour le type string qu'il n'y a pas de membre par défaut.

Bref je ne comprend toujours pas.
Je pense que je vais mettre un système de log pour savoir ce que vaut chaque variable vu que je n'arrive pas à avoir l'erreur en mode debug sur mon pc...

Je vous tien au courant...
14/12/2010, 00h00
tomlev

Citation:

Envoyé par Sankasssss

Après vérification myRow est bien de type datarow :(

En regardant de plus près l'erreur :

Je trouve bizarre que c'est pour le type string qu'il n'y a pas de membre par défaut.

:koi:
Vraiment bizarre... Même en regardant ton code sous tous les angles possibles, je vois vraiment pas ce qui cloche :?

En plus, si myRow est bien déclaré explicitement, je ne vois toujours pas pourquoi il utilise le late binding.

Et String a bien un membre par défaut, la propriété Chars (qui est son indexeur), mais il prend en paramètre un entier, pas une chaine...

Bref, je pense qu'il nous manque des éléments... tu peux poster la pile (StackTrace) de l'exception ?

Citation:

Envoyé par Sankasssss

Je pense que je vais mettre un système de log pour savoir ce que vaut chaque variable vu que je n'arrive pas à avoir l'erreur en mode debug sur mon pc...

Bonne idée. D'ailleurs, pas la peine de le faire partout, fais le juste dans un catch qui intercepte la MissingMemberException, et log le type et la valeur de myRow
15/12/2010, 20h10
Sankasssss
Bonsoir,
après avoir mi le système de traçage j'ai détecté que dans la fonction de remplissage qui posait problème je faisais un test sur la longueur d'un champs qui ce trouvait en plein milieux d'un tas de remplissage de propriété et si il dépassait une longueur j'essayais de faire un substring qui n'en était pas, exemple :
Code:

1 2 3 4 5 6 if cStr(rowT1("nom")).length > 10 then rowT2("nom")= rowT1("nom")(0,10) else rowT2("nom")= rowT1("nom") endif
je devais être bien fatigué ce jours la (ou bien dérangé) :roll:
J'ai donc changé en :
Code:

1 2 3 4 5 6 if cStr(rowT1("nom")).length > 10 then rowT2("nom")= cStr(rowT1("nom")).substring(0,10) else rowT2("nom")= rowT1("nom") endif
Et sa va beaucoup mieux du coup :oops:

Je suis content que se ne soi que ca mais honteux de ne pas l'avoir vu directement et d'avoir du mettre un log dessus pour le trouvé.

Merci tomlev pour ton suivi :ccool: