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.
dimanche 23 novembre 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
