Accueil > Logiciels, Microsoft > Les différents serveurs Web pour développer

Les différents serveurs Web pour développer

Aujourd’hui, on va un peu parler des différents serveurs Web pour développer.
Enfin, de trois en particuliers : le serveur de développement ASP.Net (aka Cassini), IIS et IIS Express.

Il est possible de paramétrer les serveurs Web pour un projet (*.csproj) à partir des propriétés de ce dernier, dans l’onglet « Web ».
Cependant, il faut bien garder en mémoire que ce paramétrage est totalement indépendant de la configuration de compilation. Il est donc parfaitement impossible d’utiliser Cassini en développement et IIS en release ! (et ça, c’est bien dommage !).

Il est par contre possible que le paramétrage soit stocké par utilisateur, dans le fichier *.csproj.user qui accompagne le projet.
Ceci dit, ce n’est pas viable en conjonction avec les builds TFS (mais ça, j’en reparlerais dans d’autre(s ?) billet(s)).

 

Cassini

 
Cassini est le serveur par défaut directement intégré à Visual Studio.
On le connait souvent comme étant WebDev.WebServer40.EXE.
Il se loge dès que l’on lance le site, dans le system tray et permet d’afficher une fenêtre des plus simpliste :
Web Servers - Cassini - System Tray

Cassini est également un projet sur Codeplex, il est sous Microsoft Public License (Ms-PL, qui est assez succinte et permissive).
Cette version (comprendre non intégrée à VS) est un peu (ahem…) plus complète, question paramétrage.

Le coté pratique de Cassini, c’est qu’il est réellement bien intégré à Visual Studio et donc qu’il n’y a pas besoin de faire grand chose pour le faire fonctionner.
En fait, il n’y a RIEN à faire pour qu’il fonctionne.
Il peut également supporter les répertoires virtuels

Mais il a plusieurs inconvénients dont il faut être conscient :

  • Il s’exécute avec l’utilisateur connecté (sans pool d’application etc.), donc c’est une bonne pratique de ne pas le faire tourner sur un compte administrateur : le contexte de sécurité n’est pas le même que sous IIS.
  • Les fichiers statiques ne seront pas servis aux utilisateurs non authentifiés (par .Net) et donc pas aux utilisateurs anonymes.
  • Aucun support du HTTPS.
  • Il ne réponds qu’aux requêtes localhost (peut être modifié à partir des sources).

Visiblement, il peut y avoir d’autres différences avec IIS, mais je n’en ai jamais rencontré (ni entendu parlé).
Mais quoiqu’il arrive, Cassini ne peut pas être une cible en environnement de production, donc pour éviter les risques, il vaut quand même mieux utiliser IIS ou IIS Express.

Dans l’onglet Web, voici ce qui s’applique à Cassini :
Web Servers - Cassini - Web

 

IIS


 

IIS, c’est un peu l’artillerie lourde du serveur Web quand on développe.
Actuellement, on en est à la version 8 (sortie avec Windows Server 2012 et Windows 8).

L’inconvénient, c’est qu’il faut faire du paramétrage avant toute chose (créer les applications / répertoires virtuels), éventuellement gérer le pool d’application, etc.
Il faut aussi bien gérer le mapping quand on travaille sur plusieurs branches d’un même projet. C’est là le point noir : comme tous les projets vont utiliser le même répertoire virtuel, cela veut dire qu’à chaque chargement de la solution, VS proposera de refaire le mapping.

Bon, certes, ce n’est pas la mort, mais quand on travaille sur trois ou quatre branches différentes, ça devient vite, très vite, saoulant.
Surtout quand on veut juste lancer le site sans lancer Visual Studio (ce qui est aussi un avantage), on ne peut pas être certain, à priori, du mapping.

Par contre, il a de très gros avantages : il est complet, à l’image de la production (en général, hein ^^), il supporte le HTTPS, les pool d’applications (utile pour se connecter à une base de données, par exemple), les filtres ISAPI, l’authentification, il est possible d’ajouter des gestionnaires…
La liste est longue, très longue.
Bon, par contre, il fait pas encore le café.

A part dans le cas du développement sur différentes branches en même temps, j’avoue que c’est mon serveur préféré.
En l’utilisant, il n’y a aucune surprise quand on déploie en production.
Et puis, il fonctionne réellement SUPER bien avec les builds TFS.

Il est quand même tellement complet qu’il y a un site qui lui est dédié, le bien nommé… http://www.iis.net/
Pour ceux qui veulent un récapitulatif rapide des fonctionnalités, je vous conseille la lecture de Web Server (IIS) Overview.

Il est possible d’accéder au gestionnaire TFS via l’exécutable « inetmgr.exe » (%windir%\system32\inetsrv\InetMgr.exe), via les outils d’administration sur un Windows client (Gestionnaire des services Internet (IIS)), ou via les rôles d’un serveur.
L’interface a cette tête-là :
Web Servers - IIS - Gestionnaire

Et sur Visual Studio, c’est toujours dans l’onglet Web :
Web Servers - IIS - VS

 

IIS Express

 

Enfin, IIS Express.
Comme pour Visual Studio Express, IIS Express est une version allégée de IIS.

Dans Visual Studio, il est donc présent au même niveau que IIS (voir capture d’écran précédente), il faut juste cocher la case « Utiliser IIS Express ».
C’est dur, hein ? ^^

Ainsi, il semble fournir le meilleur des deux serveurs précédents : la puissance de IIS et la facilité d’usage de Cassini.
Bon, la réalité est un poils différente.

Je ne vais pas me lancer dans les grandes démonstrations, la présentation de Scott Guthrie est assez complète, comme point de départ : Introducing IIS Express.
Il est aussi possible de se reporter aux extensions de IIS, Chapter 6. Introduction to IIS Express et Chapter 7. Using IIS Express.
Il est aussi utile de savoir utiliser IIS Express en ligne de commandes, il suffit de faire un tour ici : Running IIS Express from the Command Line.

En pratique, IIS Express va se greffer à deux endroits.
Tout ce qui est commun va aller dans « C:\Program Files (x86)\IIS Express » (dont l’exécutable qui permet de le lancer).
Il va aussi se greffer dans les documents de l’utilisateur courant : E:\Users\\Documents\IISExpress.
A part les deux répertoires de logs, on va trouver un répertoire « config ».

Là, on va donc retrouver trois fichiers de configuration.
Les fichiers aspnet.config et redirection.config ne sont pas réellement intéressant (et à ne pas modifier, du moins à vos risques et périls).

Par contre, le fichier applicationhost.config l’est nettement plus.
Le fichier fait à peu près 900 lignes. Il est bien sûr possible de le modifier à la mano, mais…eh bien, un backup avant est très fortement conseillé🙂

C’est donc ici que l’on va retrouver, entre autres, la déclaration de tous les sites tournant sous IIS Express et qu’il est susceptible de charger.
Car oui, un truc important à savoir : IIS Express ne charge pas tous les sites, il faut lui spécifier lesquels charger, via Visual Studio (qui le fait de manière transparente) ou via ligne de commande.

Mon fichier, pour ce billet se présente comme il suit (aperçu uniquement des sites) :

        <sites>
            <site name="WebSite1" id="1" serverAutoStart="true">
                <application path="/">
                    <virtualDirectory path="/" physicalPath="%IIS_SITES_HOME%\WebSite1" />
                </application>
                <bindings>
                    <binding protocol="http" bindingInformation=":8080:localhost" />
                </bindings>
            </site>
            <site name="MvcSample" id="2">
                <application path="/" applicationPool="Clr4IntegratedAppPool">
                    <virtualDirectory path="/" physicalPath="E:\Users\Kerr\Documents\Visual Studio 2010\Projects\MvcSample\MvcSample" />
                </application>
                <bindings>
                    <binding protocol="http" bindingInformation="*:666:localhost" />
                </bindings>
            </site>
            <siteDefaults>
                <logFile logFormat="W3C" directory="%IIS_USER_HOME%\Logs" />
                <traceFailedRequestsLogging directory="%IIS_USER_HOME%\TraceLogFiles" enabled="true" maxLogFileSizeKB="1024" />
            </siteDefaults>
            <applicationDefaults applicationPool="Clr4IntegratedAppPool" />
            <virtualDirectoryDefaults allowSubDirConfig="true" />
        </sites>

Paramétrage identique à celui de IIS dans la précédente capture, la seule différence est la case à cocher.

A la base, il y aura toujours de « WebSite1 », qui est le site par défaut, ainsi que le « siteDefaults ».
Par contre, chaque site supplémentaire se retrouvera ici (comme mon site « MvcSample »).

Alors, en terme de facilité d’usage, c’est pas mal.
IIS Express fait assez bien son office quand on reste dans le cadre des développements (mieux que Cassini, je trouve, car il n’a pas ses points faibles).
Par contre, il ne fonctionne pas réellement bien avec TFS et les builds.
J’avoue avoir eu des problèmes relationnels assez flagrants avec MSDeploy (pour générer les packages zip) et IIS Express.

 

Conclusion

 
Voilà, j’espère avoir donné pas mal d’informations ou du moins les moyens de trouver les informations.

Ma préférence va et reste toujours à IIS.
Même si l’histoire des mappings est assez pénible à la longue (surtout quand on navigue dans les branches, dans une seule journée), mais ses avantages sont bien trop importants.
De plus, pour les builds TFS (j’ai passé ma semaine dessus, je ferais un ou plusieurs billets à ce sujet), c’est bel et bien IIS qui remporte la palme du serveur le plus pratique. Haut la main. Vraiment.

Catégories :Logiciels, Microsoft
  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :