Discussion :

[Sankasssss]

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 :

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

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 :

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

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

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

[tomlev]

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)

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

[Sankasssss]

Bonsoir et merci à vous pour vos réponses

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.

+

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 )

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.

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.

[tomlev]

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

[Sankasssss]

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

En regardant de plus près l'erreur :

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

[tomlev]

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.

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 ?

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

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é)
J'ai donc changé en :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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