AG_E_UNKNOWN_ERROR [Line: 7 Position: 34]
Voici une bien drôle d'erreur qui a surgit dans un de mes projets en SilverLight. Après avoir fait de nombreuses recherches, il reste difficile à déterminer pourquoi survient cette erreur.
Voici une liste non-exhaustive des symptomes observés :
- La compilation se déroule sans problème
- Tant qu'on affiche pas l'aperçut graphique il n'y a aucun message d'erreur
- L'aperçut graphique d'un l'UserControl qui en contient un autre que vous avez créé est altéré et inutilisable
- Ne pas imbriquer les UserControl fait disparaitre le problème
- Ne pas utiliser de style definit dans App.xaml dans l'UserControl enfant fait disparaitre le problème
- Le message AG_E_UNKNOWN_ERROR indique une ligne où rien ne semble anormal
- Lorsqu'on lance l'application, tout se déroule sans problème
Il s'agit clairement d'une gène lorsqu'on effectue le design de son application avec visual studio 2008. Bien sur, il est toujours possible de faire avec et de valider son travail lors de l'execution, mais cela reste vraiment contraignant. De plus, le message d'erreur en lui même n'est pas du tout explicite et j'adresse par avance tout mes remerciements à celui qui me trouveras une note constructive à ce sujet dans la msdn.
Voici un récapitulatif non exhaustif des causes de ce message :
- Vous essayé d'insérer un UserControl que vous avez créé dans un autre UserControl
- L'UserControl inséré ne possède pas de constructeur publique
- Vous avez entrer du code dans le constructeur de L'UserControl inséré
- L'UserControl inséré utilise des styles en StaticResource déclaré dans App.xaml
- Il y a des erreurs ou des doublons dans les styles d'App.xaml
Des causes un peu différentes à mon avis peuvent également provoquer le message, en rapport avec les media elements ou avec le passage de la version 1.1 à 2.0 du framework. Si le message est le même, je ne pense résolument pas qu'il exprime le même problème.
A l'heure actuelle, je n'est pas encore trouvée de solution qui permette de corriger cette erreur. Espérons que l'équipe de développement de SilverLight ou de Visual Studio soit à l'écoute et nous publie un correctifs prochainement !
Affichage des articles dont le libellé est Visual Studio 2008. Afficher tous les articles
Affichage des articles dont le libellé est Visual Studio 2008. Afficher tous les articles
jeudi 18 décembre 2008
samedi 22 novembre 2008
Correspondance ambiguë trouvée.
Voila une autre curiosité de .Net. Aujourd'hui, j'entreprends de publier le site web sur lequel je travaille en mode dev depuis un petit moment. Je publie et je lance le site, et là, surprise :
Erreur du serveur dans l'application '/'.
Message d'erreur de l'analyseur: Correspondance ambiguë trouvée.
Erreur source:
Tout content de cette nouvelle erreur, je vais à la recherche d'une solution sur internet. Comme d'habitude, très peu de renseignements sur le message de français. Je vais donc faire un petit tour du coté des options de globalisation de IIS pour finalement obtenir la correspondance en anglais : Ambiguous match found.
Cependant, on peut trouver cet article de Peter Johnson qui donne suffisamment d'indices pour résoudre le problème. Pour une raison étrange, il ne faut pas tenter de faire cohabiter deux variables dont les noms diffèrent uniquement par la case, l'une déclarée dans l'aspx ( ou l'ascx aussi comme c'est le cas ici ) et l'autre déclarée dans le .cs. Pourtant à la compilation, il n'y a aucune erreur, et encore moins de warning.. et puis tout marche très bien tant qu'on essaye pas de publier le site.
Pour résoudre le problème, il n'y a pas 36 solutions : il faut rechercher dans l'aspx et dans le .cs les variables qui pourraient entrer en conflit. Certains parlent d'utiliser Reflector pour mettre en évidence ces variables, moi je n'ai pas trouvé cela très utile au final.
Quoi qu'il en soit, Microsoft devrait faire un effort pour documenter un peu mieux ce problème ( ce bogue ? ) sur lequel on peut facilement passer beaucoup de temps vu la limpidité du message d'erreur.
Erreur du serveur dans l'application '/'.
Erreur d'analyse
Description : Une erreur s'est produite au cours de l'analyse d'une ressource requise pour répondre à cette demande. Veuillez consulter ci-dessous les détails relatifs à l'erreur d'analyse en question, puis modifier votre fichier source de manière appropriée.Message d'erreur de l'analyseur: Correspondance ambiguë trouvée.
Erreur source:
Ligne 1 : <%@ control language="C#" autoeventwireup="true" inherits="UserControls_MonControle, App_Web_uiksj7tb" %> |
Tout content de cette nouvelle erreur, je vais à la recherche d'une solution sur internet. Comme d'habitude, très peu de renseignements sur le message de français. Je vais donc faire un petit tour du coté des options de globalisation de IIS pour finalement obtenir la correspondance en anglais : Ambiguous match found.
Cette fois ci, il y a plus de résultats et beaucoup convergent vers un article de Eran Sandler : "Ambiguous match found" error and how he solved it". Malheureusement, le blog n'existe plus depuis un petit moment.
Cependant, on peut trouver cet article de Peter Johnson qui donne suffisamment d'indices pour résoudre le problème. Pour une raison étrange, il ne faut pas tenter de faire cohabiter deux variables dont les noms diffèrent uniquement par la case, l'une déclarée dans l'aspx ( ou l'ascx aussi comme c'est le cas ici ) et l'autre déclarée dans le .cs. Pourtant à la compilation, il n'y a aucune erreur, et encore moins de warning.. et puis tout marche très bien tant qu'on essaye pas de publier le site.
Pour résoudre le problème, il n'y a pas 36 solutions : il faut rechercher dans l'aspx et dans le .cs les variables qui pourraient entrer en conflit. Certains parlent d'utiliser Reflector pour mettre en évidence ces variables, moi je n'ai pas trouvé cela très utile au final.
Quoi qu'il en soit, Microsoft devrait faire un effort pour documenter un peu mieux ce problème ( ce bogue ? ) sur lequel on peut facilement passer beaucoup de temps vu la limpidité du message d'erreur.
Lorsque Visual Studio 2008 devient instable..
Après quasiment deux jours d'exaspération pendant lesquels Visual Studio n'a pas cessé de planter, je me suis attaqué à la tâche difficile de comprendre pourquoi soudainement plus rien ne marchait !
En résumé, la régénération complète du projet et de ses DLL échouaient une fois sur deux et l'ajout d'un évènement Click sur un ContextMenu fraichement ajouté à ma WinForm faisait systématiquement redémarrer Visual Studio.
Difficile de travailler dans ces conditions. Dieu merci, le projet sur lequel je suis est sous SVN, ce qui m'a permit de retrouver une version du mon code non-bogué. Le problème venait donc bien du code et pas de Visual Studio Team System 2008 que je venais d'installer approximativement dans le même temps que l'apparition des symptomes.
Après avoir identifié la version de mon code qui était défectueuse, j'ai mis à jour un à un les fichiers modifié de la version supérieure en espérant trouver celui qui serait en cause. Pour ne rien faciliter, chacun des fichiers que j'ajoutais contenait des modifications qui m'empechait de compiler si d'autres fichiers n'était pas mis à jour également.
Finalement, j'ai mis en évidence la cause de mon souci :
Plus précisement, celà viens du get qui retourne la propriété elle même à la place de la variable. Cette petite erreur d'inattention se détecte généralement rapidement à l'execution.. pour peu qu'on en vienne à utiliser cette classe. Dans mon cas, cette propriété est très rarement utilisée et je n'ai donc pas eu l'occasion de lever une exception.
En revanche, cette propriété fait partie d'un UserControl qui lui même est inséré dans la WinForm de mon projet qui me causait tant de soucis. D'une manière où d'une autre ( peut être le InitComponent de ma WinForm ) cette propriété devais être appelé par Visual Studio au moment du design, ce qui a déclenché toute la série d'instabilité qui suivirent.
En conclusion, il vaut mieux utiliser l'encapsulation automatique de Visual Studio plutôt que d'écrire vos propriétés à la main pour éviter ces erreurs stupides qui peuvent facilement faire perdre deux jours de travail !
En résumé, la régénération complète du projet et de ses DLL échouaient une fois sur deux et l'ajout d'un évènement Click sur un ContextMenu fraichement ajouté à ma WinForm faisait systématiquement redémarrer Visual Studio.
Difficile de travailler dans ces conditions. Dieu merci, le projet sur lequel je suis est sous SVN, ce qui m'a permit de retrouver une version du mon code non-bogué. Le problème venait donc bien du code et pas de Visual Studio Team System 2008 que je venais d'installer approximativement dans le même temps que l'apparition des symptomes.
Après avoir identifié la version de mon code qui était défectueuse, j'ai mis à jour un à un les fichiers modifié de la version supérieure en espérant trouver celui qui serait en cause. Pour ne rien faciliter, chacun des fichiers que j'ajoutais contenait des modifications qui m'empechait de compiler si d'autres fichiers n'était pas mis à jour également.
Finalement, j'ai mis en évidence la cause de mon souci :
private MaClasse instance;
public MaClasse Instance
{
set
{
instance = value;
}
get
{
return Instance;
}
}
Plus précisement, celà viens du get qui retourne la propriété elle même à la place de la variable. Cette petite erreur d'inattention se détecte généralement rapidement à l'execution.. pour peu qu'on en vienne à utiliser cette classe. Dans mon cas, cette propriété est très rarement utilisée et je n'ai donc pas eu l'occasion de lever une exception.
En revanche, cette propriété fait partie d'un UserControl qui lui même est inséré dans la WinForm de mon projet qui me causait tant de soucis. D'une manière où d'une autre ( peut être le InitComponent de ma WinForm ) cette propriété devais être appelé par Visual Studio au moment du design, ce qui a déclenché toute la série d'instabilité qui suivirent.
En conclusion, il vaut mieux utiliser l'encapsulation automatique de Visual Studio plutôt que d'écrire vos propriétés à la main pour éviter ces erreurs stupides qui peuvent facilement faire perdre deux jours de travail !
Inscription à :
Articles (Atom)
Articles
