LuaNet ne connait que l'ANSI

J'aime bien les scripts LUA. C'est rapide à mettre en œuvre, la syntaxe est claire, souple et ils remplissent très bien leur rôle dès qu'on souhaite séparer le coeur de l'application et d'une partie du code métier qui varie en fonction des postes, des clients, des installations, des configurations. Les scripts de manière générale permettent d'avoir un peu de souplesse sans avoir à recompiler tout le projet et LUA est vraiment la réponse que je préfère pour répondre à cette problématique.

Mais, LuaNet, qui est l'implémentation que j'utilise pour C#, est incapable de traiter les fichiers encodés en Unicode, ou en UTF-8, ou en quoi que ce soit d'autre que l'ANSI. La fonction DoFile qui parait si pratique retourne systématiquement un joli "unexpected symbol near 'ï'" et nous voila dans l'obligation de convertir obligatoirement tout les nos fichiers lua au format ANSI. Tout de même, je ne sait pas comment est écrite cette fonction, mais il serait si facile de gérer l'UTF-8 que je me demande pourquoi cela n'a pas déjà été fait.

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

---

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 :

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 !