Vous en rêviez : Un client lourd DotNet peut héberger une WebApp complète sans avoir à installer IIS sur chaque poste.
Imaginez. Souvent, en entreprise, le schéma classique consiste en une base de donnée hébergée à l'entreprise, et des applications dites 'clients lourds' installées chez les commerciaux ou les clients. Généralement ces 'clients lourds' sont développés à l'aide d'une base Access, et avec une interface utilisateur constituée de WinForms (si ce n'est parfois directement en VBA).
Problème : Les interfaces à base de WinForm sont généralement laides, condensées, complexes, et incompréhensible pour un néophyte bien plus habitué à naviguer dans des interfaces Web. Je vous propose ici LA solution : Créer une 'WebSkin' à votre affreux 'client lourd' pour le rendre plus digeste à vos commerciaux ou clients. Profitez de la puissance de ASP.Net pour réaliser une interface claire, basée sur les pages qui pourront être données à de vrais Web Designers.
Grand habitué de csharpfr.com, ayant souvent trouvé des sources intéréssantes pour mes applications, sur ce sujet que je savais possible, je n'ai malheureusement trouvé aucune source. J'ai donc décidé de retrousser mes manches et de m'y coller moi-même. Je vous livre le résultat d'une petite semaine de travail, largement aidé par le livre référence "Pratique de .Net 2 et C#" de Patrick Smacchia, que je ne saurais que trop conseiller à tous les développeurs C#.
Cet exemple est réalisé avec Visual C# 2008 Express, et Visual Web Developper 2008 Express.
Cette technique est extrêmement puissante et permet d'héberger simplement la totalité d'une WebApp ASP.Net sur chaque poste ou est installée le 'client lourd', accessible en localhost sans connexion internet. On obtient donc une application déconnectée de la base entreprise, mais consultable localement en mode déconnecté à travers une belle interface Web.
Il y a un BUG sous Windows Vista qui bloque le HttpListener pour des questions de sécurités. Il doit y avoir un bout de code à rajouter pour que ca fonctionne sous Vista, mais lequel ? J'ai chercher un peu sur le web mais je n'ai rien trouvé.
Je ne suis pas Web Developper (bien que je vais devoir m'y mettre) donc l'exemple de la WebApp fournie est très sommaire. Juste pour vérifier que la technique fonctionne. A ce propos le code qui ne semble pas marcher, et c'est logique puisqu'on se passe de IIS, est la redirection de la page à la fin d'un traitement :
this.Response.Redirect("Welcome.aspx");//BUG in Local Server ASPNET
Il faut donc feinter et inclure une fonction javascript dans la page retournée à la fin du traitement qui fait la redirection directement depuis le browser de l'utilisateur. Le code ci-dessus est alors remplacé par :
//use body.onLoad
HtmlGenericControl body = this.FindControl("body") as HtmlGenericControl;
body.Attributes["onLoad"] = "RedirectWelcome()"; //nom de la fonction javascript
Laquelle fonction javascript est écrite directement dans la page aspx :
<script language="javascript" type="text/javascript">
function RedirectWelcome() {
window.location = "Welcome.aspx";
}
</script>
Voilà l'astuce. Pour le reste tout semble fonctionner normalement (avec IE).
Bonne lecture, et bon tests...
MAJ V2 V3:
J'ai du intégrer cette exemple dans mon application, et pour cela j'ai du revoir tout le code de l'exemple. J'ai donc fais une V2 et une V3, dont le résultat est une dll bien pratique qui doit être insérée dans le dossier /bin/ de votre WebApp. Puis il suffit d'implémenter la classe 'ServerASPNET' qui encapsule toute la complexité du fonctionnement du server ASPNET local. On peut même instancier plusieur 'ServerASPNET', un pour chaque WebApp, et ainsi constituer une ferme de WebApp. A partir de la pourquoi pas redevelopper un serveur Web complet compatible ASPNET ?
En particulier il doit être possible de pallier le BUG de redirection à la fin d'un traitement (voir le code).
MAJ V4:
J'ai ajouté quelques fonctionnalités indispensables :
- Gestion des sous-repertoires de la WebApp (dont App_GlobalRessources)
- Gestion des fichiers Non-ASP (images, css, html)