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 !
jeudi 18 décembre 2008
dimanche 14 décembre 2008
Binding en Silverlight 2.0
Avec WPF, Microsoft à introduit une nouvelle façon de lier des données aux contrôler par la syntaxe {Binding}. Cette syntaxe est très légère et incroyablement efficace lorsqu'on sait s'en servir. Vous pouvez consulter DataBinding Quick Reference pour faire un tour d'horizon de cette syntaxe.
Silverlight lui aussi permet de faire du binding de cette façon, mais de façon plus limité. Par exemple, le très utile ElementName, qui permet de cibler un autre contrôle par son nom, n'est pas disponible. En WPF, il suffit de faire comme le décrit Pascal Cabanel sur son blog.
Pourtant, avec Silverlight, c'est un peu plus complexe. La façon la plus simple est de passer par des évènements et de mettre à jour les DataContexte de chaque contrôle à chaque changement. Ca marche très bien, surtout si l'application n'est pas très complexe.
La solution qui est recommandée par Microsoft, je l'ai trouvé sur un ce webcast. Il faut créer une classe intermédiaire qui implémente INotifyPropertyChanged, un Controller, et qui va faire le lien entre tous les contrôles et sur lequel va reposer tout notre binding.
Silverlight lui aussi permet de faire du binding de cette façon, mais de façon plus limité. Par exemple, le très utile ElementName, qui permet de cibler un autre contrôle par son nom, n'est pas disponible. En WPF, il suffit de faire comme le décrit Pascal Cabanel sur son blog.
Pourtant, avec Silverlight, c'est un peu plus complexe. La façon la plus simple est de passer par des évènements et de mettre à jour les DataContexte de chaque contrôle à chaque changement. Ca marche très bien, surtout si l'application n'est pas très complexe.
La solution qui est recommandée par Microsoft, je l'ai trouvé sur un ce webcast. Il faut créer une classe intermédiaire qui implémente INotifyPropertyChanged, un Controller, et qui va faire le lien entre tous les contrôles et sur lequel va reposer tout notre binding.
dimanche 23 novembre 2008
Windows Server 2008 + Silverlight + IIS7 + WCF Service : Erreur 404 sur fichier .svc
Il y a un petit point à bien vérifier lorsqu'on souhaite installer une application Silverlight sur un site qui tourne sous IIS7.
Lorsque Silverlight communique avec un site via un service WCF, il cible un fichier .svc qui permet normalement d'accéder au wsdl de notre service. En publiant mon site web sur Windows Server 2008, sur lequel est installé le .Net Framework 3.5, ce cher fichier .svc nous retourne une jolie erreur 404, rendant toute l'application Silverlight inutilisable.
Après quelques recherches je trouve un premier article qui décrit bien les symptômes du problème. Hélas, la solution préconisée qui consiste à renseigner les informations MIME des fichier .svc dans l'outil de configuration d'IIS7 n'est pas très efficace, et le problème persiste.
En cherchant encore un peu, je trouve le blog de Jean-Paul Smith qui a lui aussi été confronté au problème. Selon lui, l'erreur 404 pourrait survenir lorsqu'on met à jour le Framework .Net 3.0 vers sa version RTM. Mais voila, ce n'est pas mon cas ici. Toutefois, lors de l'installation IIS7, je n'avais pas encore installé le Framework .Net 3.5. Petit doute donc, mais je pense quand même que Windows Server 2008 ne devrait pas avoir de difficulté là dessus. Malgré cela, je décide de suivre les instructions de Jean-Paul Smith qui passent tout de même par une réinstallation de IIS7. Heureusement, c'est très rapide à faire et il n'y a rien à reconfigurer après coup. En pratique, cela ne résout hélas pas notre problème.
C'est David Waddelton qui m'a épargner des heures d'errances grâce à son blog. La solution est vraiment toute simple, mais à savoir. Il suffisait d'aller dans le Gestionnaire de Serveur et d'ajouter la fonctionnalité suivante :
"Fonctionnalités .Net Framework 3.0 \Activation de Windows Communication Fondation"
Après cela, j'ai pu immédiatement accéder à mon fichier .svc et à l'application Silverlight.
Il est intéressant de noter que le type MIME pour les fichier .svc n'a pas été créé avec cette manipulation et que cela ne pose aucun problème.
Lorsque Silverlight communique avec un site via un service WCF, il cible un fichier .svc qui permet normalement d'accéder au wsdl de notre service. En publiant mon site web sur Windows Server 2008, sur lequel est installé le .Net Framework 3.5, ce cher fichier .svc nous retourne une jolie erreur 404, rendant toute l'application Silverlight inutilisable.
Après quelques recherches je trouve un premier article qui décrit bien les symptômes du problème. Hélas, la solution préconisée qui consiste à renseigner les informations MIME des fichier .svc dans l'outil de configuration d'IIS7 n'est pas très efficace, et le problème persiste.
En cherchant encore un peu, je trouve le blog de Jean-Paul Smith qui a lui aussi été confronté au problème. Selon lui, l'erreur 404 pourrait survenir lorsqu'on met à jour le Framework .Net 3.0 vers sa version RTM. Mais voila, ce n'est pas mon cas ici. Toutefois, lors de l'installation IIS7, je n'avais pas encore installé le Framework .Net 3.5. Petit doute donc, mais je pense quand même que Windows Server 2008 ne devrait pas avoir de difficulté là dessus. Malgré cela, je décide de suivre les instructions de Jean-Paul Smith qui passent tout de même par une réinstallation de IIS7. Heureusement, c'est très rapide à faire et il n'y a rien à reconfigurer après coup. En pratique, cela ne résout hélas pas notre problème.
C'est David Waddelton qui m'a épargner des heures d'errances grâce à son blog. La solution est vraiment toute simple, mais à savoir. Il suffisait d'aller dans le Gestionnaire de Serveur et d'ajouter la fonctionnalité suivante :
"Fonctionnalités .Net Framework 3.0 \Activation de Windows Communication Fondation"
Après cela, j'ai pu immédiatement accéder à mon fichier .svc et à l'application Silverlight.
Il est intéressant de noter que le type MIME pour les fichier .svc n'a pas été créé avec cette manipulation et que cela ne pose aucun problème.
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
