Déployer ses applications web ASP.NET

Sommaire de l'article

• Différence entre Web Application et Web Site
• Utiliser IIS comme serveur Web local pour le développement à la place de Cassini
• Web Packaging
• Installation de Web Packages
• Transformation de fichier Web.Config
• Publication en un clic (One-Click Publishing)
• Déploiement de Web Site
• Déploiement de bases de données avec un Web Package
• Publier son application sur la Web Application Gallery de Microsoft

Différence entre Web Application et Web Site

Nous allons voir dans cet article les nouveautés apparues avec Visual Studio 2010 concernant le déploiement d'application Web.

La dernière étape lors d'un projet Web est le déploiement de cette application pour la rendre accessible aux utilisateurs. Ce déploiement peut être réalisé sur un serveur de production d'une entreprise ou sur un serveur d'hébergement distant par exemple. Dans tous les cas cette étape est souvent source de problèmes mais aussi de pertes de temps du fait des nombreuses opérations manuelles à réaliser. Citons par exemple :

• la modification des paramètres contenus dans le fichier Web.config ;
• la création d'une base de données de production et la gestion des droits pour celle-ci ;
• la configuration du site dans IIS (par exemple le mode d'authentification, la gestion des droits sur les répertoires, le paramétrage de l'application pool) ;
• l'installation de certificats de sécurité ;
• l'ajout d'assemblies dans le Global Assembly Cache (GAC).

Bien entendu, nous parlons ici uniquement d'un premier déploiement. Dans le cadre d'une mise à jour, il est souvent nécessaire de mettre à jour manuellement certaines pages uniquement, ou bien de paramétrer de nouveaux les exemples cités plus haut à cause de l'ajout d'une nouvelle fonctionnalité. L'arrivée de Visual Studio 2010 va changer la donne. En effet l'équipe de Microsoft a travaillé dur pour nous fournir de nombreux outils afin d'automatiser et optimiser au mieux le déploiement d'applications Web. Cet article a pour but de vous faire découvrir ces nouveaux modes de déploiement. Vous trouverez donc ici :

• le déploiement d'une Web Application via des Web Deployment Packages ;
• la transformation de fichiers Web.config ;
• la publication d'une Web Application en un clic (One-Click Publishing) ;
• les différentes méthodes de déploiement pour les Web Sites ;
• le déploiement de base de données en utilisant les Web Deployment Packages ;
• la publication de votre application sur la Web Application Gallery de Microsoft.

Avant d'entrer dans le vif du sujet, vous trouverez un petit rappel concernant les différences entre une Web Application et un Web Site.

Différence entre Web Application et Web Site

Avec Visual Studio, vous pouvez créer des Web Applications ou des Web Sites. Chaque type de projet ayant ses avantages et ses inconvénients. Gardez en tête qu'il est important de choisir le type de projet le plus approprié à vos besoins, car il n'est pas aisé de convertir un type de projet vers l'autre.

Quel type de projet choisir pour son application

Le principal critère sur lequel vous devez focaliser votre attention est de savoir comment vous avez l'intention de déployer et maintenir votre site web. Voici les principaux besoins pour lesquels Microsoft préconise d'utiliser une Web Application :

• vous souhaitez utiliser MSBuild pour compiler votre projet. Par exemple, vous pourriez vouloir ajouter des étapes avant et après la compilation ;
• vous souhaitez que Visual Studio ne génère qu'un seul et unique Assembly pour l'ensemble du site ;
• vous souhaitez pouvoir contrôler la façon dont le nom et la version de l'Assembly sont générés pour le site ;
• vous souhaitez pouvoir utiliser une classe autonome pour le code-behind de vos pages et User-Controls.

Si vous rencontrez ces différents besoins, le type de projet Web Site sera surement préféré :

• vous souhaitez être en mesure de mettre à jour des fichiers individuellement en copiant simplement les nouvelles versions ou en éditant directement ceux-ci sur le serveur ;
• vous ne voulez pas compiler explicitement votre site web en mode de configuration Release pour le déployer ;
• vous souhaitez que Visual Studio créé plusieurs Assemblies pour le site. Cela peut aller d'une Assembly par page ou par User-Control, ou une ou plusieurs Assemblies par dossier.

Résumé des différences entre un Web Site et une Web Application

Il n'y a aucune différence de performance entre un Web Site et une Web Application. La seule exception notable concerne les sites très volumineux. En effet, pour les Web Sites, la première requête après déploiement ou mise à jour du site peut nécessiter un temps de compilation long. Mais globalement, ce n'est pas un critère à prendre en compte pour choisir entre les deux types de projets.

Pour illustrer les différences citées plus haut, notamment sur la structure des deux types de projets, voici ce que donne, dans Visual Studio 2010 et en ASP.NET 4.0, la création d'un Web Application Project et d'un Web Site :

Comme indiqué plus haut, la conversion d'un Web Site vers une Web Application n'est pas toujours aisée. Aussi, voici la méthode préconisée par l'équipe Visual Studio Web Tools : Blog MSDN de l'équipe Web Dev Tools ou directement cet article MSDN

Utiliser IIS comme serveur Web local pour le développement à la place de Cassini

Vous savez surement déjà que, lorsque vous lancez une application Web avec Visual Studio pour la tester ou la débuguer, c'est le moteur Cassini qui est utilisé et non IIS comme chez votre hébergeur ou sur les serveurs de production de votre entreprise. Le serveur Web Cassini est un serveur Web simple, entièrement géré, qui héberge ASP.NET. Le serveur Web Cassini associe les éléments suivants :

• un port d'écoute HTTP simple créé à l'aide de System.Net.Sockets ;
• un exemple d'hébergement d'ASP.NET créé à l'aide d'API System.Web.Hosting. Cela vous permet d'héberger ASP.NET à partir de n'importe quelle application gérée.

Les limitations de fonctionnalités du serveur Web Cassini sont entre autres :

• il peut héberger une seule application ASP.NET par port ;
• il ne prend pas en charge HTTPS ;
• il ne prend pas en charge l'authentification ;
• il répond uniquement aux requêtes localhost.

Pourquoi Cassini est-il couramment utilisé dans ce cas et préféré dans beaucoup d'entreprises ? Tout simplement parce qu'il ne nécessite pas d'installation, qu'il est prêt à l'emploi et qu'il n'est pas nécessaire d'être administrateur local de sa machine de développement. Mais l'élément le plus important est que le Cassini ne représente pas votre application telle qu'elle sera une fois déployée. Afin d'éviter toute surprise, voici la marche à suivre pour utiliser IIS comme serveur Web local pendant vos développements avec Visual Studio 2010.

Notez qu'il est nécessaire d'avoir IIS sur sa machine (rien d'étonnant me direz-vous…), mais aussi d'exécuter Visual Studio en mode administrateur. Pour le mode administrateur, si votre compte utilisateur Windows est effectivement administrateur sur la machine, un clic droit sur le raccourci ou l'exécutable de Visual Studio 2010 fera apparaître l'option " Exécuter en tant qu'administrateur ".

Reprenons le projet WebApplicationBidon présenté dans la figure précédente. Il s'agit d'un projet ASP.NET Web Application de base, comme indiqué dans la figure suivante :

Une fois votre application créée, allez dans la page Propriétés du projet (clic droit sur le projet ou plus simplement : ALT+Enter) et ouvrez l'onglet Web. Sélectionnez ensuite " Use Local IIS Web server " :

Vous pouvez ensuite cliquer sur le bouton "Create Virtual Directory". Désormais, lors du lancement de l'application en mode debug ou non, nous accédons directement à IIS en localhost :

Toutefois, il se peut que vous n'ayez pas installé sur votre poste la métabase pour le mode de compatibilité IIS. Dans ce cas, allez dans le Panneau de Configuration, puis Programmes et fonctionnalités, puis Activer ou désactiver des fonctionnalités Windows. Et sélectionnez les options présentes sur la capture ci-dessous :

Si vous utilisez Windows Server 2008 R2, vous pouvez facilement installer IIS dans le Gestionnaire de Serveur et via l'action "Ajouter des fonctionnalités".

Web Packaging

C'est LA nouveauté qui va révolutionner le déploiement d'applications Web, mais aussi faciliter la vie aux développeurs, aux administrateurs IIS et, dans une moindre mesure aux administrateurs de base de données qui seront beaucoup moins sollicités lors des déploiements. Comme expliqué précédemment, l'étape du déploiement dans un projet est souvent source de problèmes mais aussi de pertes de temps du fait des nombreuses opérations manuelles à réaliser. Les Web Packages vont nous permettre d'automatiser tout cela.

Qu'est-ce qu'un Web Package

Un Web Package est une unité atomique, transparente et descriptive qui représente votre application Web et qui permet de la déployer facilement sur n'importe quel serveur Web IIS. C'est un fichier .zip qui contient non seulement le contenu du site, mais aussi ses dépendances comme les paramètres IIS, les bases de données, les Assemblies du Global Assembly Cache(GAC), les clés de registres, les paramètres de sécurité, etc.

Ce nouveau concept pour le déploiement d'applications Web a été introduit avec l'outil Microsoft Web Deployment Tool, mais sera démocratisé avec l'arrivée de Visual Studio 2010.

Présentation de Microsoft Web Deployment Tool (ou MsDeploy, ou Web Deploy)

Microsoft Web Deployment Tool, ou MS Deploy, est un nouvel outil proposé par l'équipe de développement IIS qui simplifie la migration, la gestion et le déploiement de serveurs IIS, de Web Applications et de Web Sites. Les administrateurs peuvent utiliser la fonction de script en ligne de commande avec MsDeploy pour synchroniser IIS 6.0 et 7.0 ou bien pour migrer un serveur IIS 6.0 vers un serveur IIS 7.0.

Pour cet article et plus généralement en ce qui concerne les développeurs, cet outil permet aux utilisateurs délégués d'utiliser IIS Manager pour déployer des applications ASP.NET (mais aussi PHP) sur un serveur IIS 7.0. MsDeploy est intégré avec PowerShell, Visual Studio 2010 et est compatible avec le Web Platform Installer.

Comment fonctionne le déploiement Web avec Visual Studio 2010 et MSDeploy

Visual Studio 2010 utilise MsDeploy dans les coulisses pour faciliter le déploiement des applications Web. Afin de mieux maîtriser le Packaging de vos futures applications développées en ASP.NET 4.0, il convient de jeter un œil sur le fonctionnement de cet outil.

MsDeploy vous permet de déployer un site ou de répliquer celui-ci sur une ferme de serveurs Web en utilisant une application Web d'origine ainsi que ses dépendances. Pour résumer, MsDeploy utilise un concept très simple : il s'agit d'utiliser une source pour l'appliquer à une destination. Essayons de comprendre quelles sont les sources et les destinations possibles.

Source :

• si vous souhaitez déployer le site que vous développez sur votre machine de développement, alors ce site devient la source ;
• si vous avez votre contenu Web stocké dans un gestionnaire de sources et que vous avez une usine de développement qui est paramétrée pour compiler et déployer automatiquement, alors l'usine de développement devient la source ;
• si un Web Package vous est envoyé par quelqu'un et que vous tentez de l'installer sur votre machine de développement, alors ce Web Package devient la source.

Destination :

• si vous déployez une application Web sur un serveur de test, alors ce serveur de test est la destination ;
• si vous créez un Web Package de votre application en utilisant MsDeploy, alors ce Web Package devient la destination ;
• si vous déployez sur votre machine de développement pour des tests, alors dans ce cas, votre machine devient la destination.

Comme vous avez pu le constater, les concepts de source et de destination sont assez simples. La raison pour laquelle ils sont si intéressants est que lorsque vous configurez vos paramètres de déploiement dans Visual Studio 2010, celui-ci crée quelque chose que nous appelons Source Manifest, qui est en fait un fichier XML. Ce fichier alimente MsDeploy lors de la création du Web Package. Ci-dessous, un schéma représentant les concepts évoqués précédemment :

Process de génération de Web Package

Source Manifest est un simple fichier XML qui indique à MsDeploy quelles sont les Providers à invoquer sur la machine source. La question qui se pose est : qu'est-ce qu'un Provider MsDeploy ? Un provider MsDeploy est un module que le moteur MsDeploy invoque pour réaliser deux principales tâches conceptuelles :

• sur la machine source pour obtenir le contenu directement depuis son emplacement. Par exemple, si vous avez une base de données attachée à votre site Web, alors le DB Provider utilisera la source pour extraire les données et le schéma de la base afin de les convertir en script SQL qui sera inclus dans le Web Package ;
• sur la machine de destination pour mettre le contenu au bon endroit, par exemple, s'il y avait des scripts SQL inclus dans le Web Package, alors sur la machine de destination, le DB Provider sera appelé pour exécuter ces scripts et ainsi mettre en place la base de données.

MsDeploy est fourni avec de nombreux providers comme :

• un provider pour les paramètres IIS (pour les versions 5.1, 6.0, et 7.0) ;
• DB Provider pour SQL Server ;
• un provider pour gérer le Global Assembly Cache (GAC) ;
• un provider pour gérer les objets COM ;
• un provider pour gérer les clés de registres ;
• etc.

En se basant sur les paramètres de votre projet, Visual Studio 2010 crée un fichier XML Source Manifest qui servira à alimenter MsDeploy pour créer un Web Package ou déployer votre application Web. Le schéma ci-dessous montre comment MsDeploy procède :

En plus de créer le fichier XML Source Manifest, Visual Studio 2010 crée également le fichier Destination Manifest pour vous. Lorsque vous êtes prêt à le déployer sur la machine de destination, vous pouvez alimenter MsDeploy avec le Web Package et le Destination Manifest. Vous pouvez bien entendu changer dans le Destination Manifest des paramètres comme le nom de l'application dans IIS, ou bien la Connection String pour votre base de données de production.

Il n'est évidemment pas possible d'avoir un provider pour chaque besoin des développeurs. Néanmoins, la liste fournie par défaut en comble une bonne partie. Surtout, et comme indiqué sur le schéma précédent, il est possible de créer soi-même un provider pour MsDeploy.

Les avantages à utiliser des Web Packages

Pour vous démontrer rapidement les avantages à utiliser des Web Packages, je vais m'inspirer de 10 bonnes raisons citées par Vishal Joshi (Senior Program Manager chez Microsoft).

1. Avoir tout votre contenu Web et ses dépendances comme les paramètres de IIS ou de votre base de données dans un seul fichier .zip vous permet de transporter votre application facilement n'importe où.
2. Si le Web Package contient également le code source de l'application, vous pouvez répliquer facilement votre environnement de développement sur un autre poste. Imaginez être en mesure de recréer un projet sur votre propre machine en recevant par mail un simple fichier .zip.
3. Si vous déployez votre application sur une ferme Web, alors le déploiement du Web Package vous facilitera grandement la tâche.
4. Si vous développez votre application pour que la communauté l'utilise, alors partager le fichier .zip du Web Package vous permettra de créer un modèle utilisable très facilement
5. La Web Application Gallery de Microsoft, qui dans un avenir proche va devenir le lieu par excellence pour trouver des applications Web réutilisables, utilise le format des Web Packages. Donc, créer un Web Package vous donne l'opportunité de rendre votre application disponible dans la Web Application Gallery.
6. La plupart des processus de création de Web Packages sont automatisés et vous n'avez pas besoin d'écrire des actions personnalisées, comme c'est le cas avec Microsoft Windows Installer (MSI).
7. La création de Web Packages peut être automatisée avec vos compilations nocturnes très facilement en utilisant MsBuild avec des systèmes comme Team Build ou Cruise Control.
8. Vous pouvez créer un Web Package pour différentes version de votre application Web et facilement utiliser des packages correspondant à une version pour permettre un rollback vers n'importe quelle version. Cette fonctionnalité est très utile pour les mises à jour d'applications critiques en production.
9. Vous obtenez gratuitement l'interface graphique standardisée pour installer les Web Packages avec IIS Manager. Et si vous n'aimez pas utiliser l'interface graphique, le Web Package peut être installé en mode ligne de commande.
10. La plupart des outils automatisés, les providers, nécessaires au Packaging de votre application Web et à ses dépendances sont à disposition.

Création de Web Packages avec Visual Studio 2010 et MSDeploy

Entrons maintenant dans le vif du sujet avec un exemple. Reprenons le projet WebApplicationBidon qui, comme son nom l'indique, est un projet de type Web Application et non un Web Site. En regardant dans Visual Studio 2010 la fenêtre Propriétés de votre projet (clic droit sur le projet puis Propriétés ou ALT+Enter lorsque le projet est sélectionné, pour aller plus vite), vous remarquez que de nouveaux onglets ont fait leur apparition par rapport à la version 2008. Il s'agit des onglets " Package/Publish Web " et " Package/Publish SQL ". Nous allons nous intéresser au premier, le second sera abordé plus loin, dans la partie expliquant le déploiement de base de données avec les packages. Voici le contenu de ce nouvel onglet :

Pour ce nouvel onglet, regardons plus en détail les différentes options affichées.

• Configuration et Platform : ces éléments ne sont pas nouveaux puisque déjà présents dans Visual Studio 2008. La configuration en mode débug est très utile par exemple pour déployer l'application sur un serveur de test et avoir notamment accès au PDB. Le mode Release l'exclut. Il est utile de rappeler que l'on peut très bien créer soi-même d'autres modes de configuration, par exemple pour l'environnement UAT. Pour ce faire, allez dans le menu Build puis Configuration Manager.

La première section Items to deploy permet de décider quel type de contenu vous voulez réellement déployer ou inclure dans votre Package. Elle s'applique donc à tous les types de déploiement.

• Fichiers à déployer : cette première liste est réglée par défaut sur « Only files needed to run this application ». Cette option est rarement changée car elle permet d'inclure tous les fichiers de votre projet, à l'exception du code source, des fichiers projets et d'autres types de fichiers non nécessaires au déploiement. Les autres options sont « All files in this project » (tous les fichiers inclus dans le projet sont déployés sur le serveur de destination. Les fichiers qui sont dans le dossier du projet, mais non inclus dans le projet sont exclus) et « All files in this project folder » (tous les fichiers du dossier du projet, même exclus du projet sont déployés).
• Exclude generated debug symbols : ne pas cocher cette option implique que les fichiers .pdb seront déployés sur le serveur. Ces fichiers sont nécessaires pour le débugage, mais généralement utilisés sur un serveur de test et non un serveur de production.
• Exclude files from the App_Data folder : le dossier App_Data dans la version Web Developer de Visual Studio peut être considéré comme un magasin de données. Il est créé en-dessous du dossier racine du site et est généralement utilisé pour stocker les fichiers .mdf de SQL Server Express, ou encore les fichiers XML. Il vous suffit de cocher cette case pour exclure du déploiement les fichiers contenus dans ce dossier.

La deuxième section Items to deploy est consacrée uniquement aux déploiements via Web Deploy.

• Include all databases configured in Package/Publish SQL tab : cette option vous permet de spécifier si vous voulez ou non inclure toutes les bases de données que vous avez paramétrées dans l'onglet Package/Publish SQL. Si cette case n'est pas cochée, aucun script SQL ne sera exécuté lors du déploiement.
• Include all IIS settings as configured in IIS Manager : cette option est très utile car elle vous permet d'inclure dans le déploiement, les paramètres du site dans IIS. En cliquant sur le lien Open Settings à droite, vous arrivez directement dans le Gestionnaire IIS pour visualiser ces paramètres. Attention tout de même, dans le cas du serveur d'un hébergeur ou d'un serveur de production de votre entreprise, vous n'aurez surement pas les droits nécessaires. Par contre, pour déployer facilement tous les paramètres IIS sur un environnement de DEV ou UAT cela s'avère très utile. Si vous cochez cette option, vous pourrez également sélectionner « Include application pool settings used by this Web project », ce qui vous permettra d'inclure également les paramètres de l'App pool dans le déploiement sur IIS

La troisième et dernière section est celle qui nous intéresse le plus : les Web Deployment Package Settings. Dans cette dernière, nous allons pouvoir définir comment le Web Package sera créé et où il doit être déployé.

• Create deployment package as a zip file : cette case à cocher permet de spécifier si vous désirez inclure votre Web Package dans un fichier .zip (très utile pour le partage entre développeurs ou dans la communauté), ou si vous désirez simplement qu'il soit sous forme de dossier. Notez que la deuxième option se révèle aussi utile, si vous souhaitez comparer les fichiers contenus dans le dossier entre deux versions du packages (avec l'outil WinMerge par exemple).
• Location where package will be created : permet de spécifier le path dans lequel sera créé le package. Selon que la création d'un fichier .zip sera cochée ou non, vous obtiendrez un fichier zip portant le nom de votre projet ou un dossier.
• IIS Web site/application name to user on the destination server : vous permet de spécifier quel site sera utilisé et quel nom portera votre application sur le serveur IIS de destination. Par défaut, l'application est déployée sur le site « Default Web Site »
• Physical path of Web application on destination server : cette option n'est disponible que si vous avez décidé d'inclure les paramètres IIS dans votre Web Package. C'est aussi une des informations des plus importantes à inclure dans votre Package, même si vous aurez la possibilité de changer ce chemin dans IIS lors du déploiement.
• Password used to encrypt secure IIS settings : vous permet de spécifier un mot de passe afin de sécuriser les paramètres IIS inclus dans le Package.

L'ensemble des options de cet onglet décrit, passons maintenant à la création d'un Package pour l'application WebApplicationBidon. Pour ce faire c'est très simple : un clic droit sur l'application puis Build Deployment Package, comme indiqué sur la figure ci-dessous.

Observons maintenant les fichiers qu'a générés Visual Studio dans le sous-dossier obj/Debug du projet :

On peut noter quatre fichiers importants :

• le Web Package lui-même : ce peut être comme ici un fichier .zip qui correspond en fait au contenu du dossier PackageTmp, ou bien un simple dossier si on a choisi de ne pas utiliser le format .zip pour notre package ;
• le script de commande .deploy : ce script créé par Visual Studio encapsule les commandes MSDeploy afin de nous permettre ne de pas avoir à taper une seule commande pour installer le package ;
• le fichier Source Manifest qui, comme indiqué précédemment, est un simple fichier XML qui indique à MsDeploy quels sont les Providers à invoquer sur la machine source ;
• le fichier Set Parameters qui est un fichier XML comprenant les paramètres que nous avons spécifiés pour le déploiement.

Regardons de plus près le contenu des deux fichiers XML. Tout d'abord, le fichier Source Manifest :

Et le fichier SetParameters :

Comme on peut le constater, ces deux fichiers contiennent les principaux paramètres utiles au déploiement comme le nom de l'application dans IIS, la Connection String, etc. On peut également indiquer au provider setAcl une Access Control List (ACL) pour un fichier ou un dossier. Les ACL sont utilisées pour définir l'accès et les permissions qu'un utilisateur ou une application possède pour un fichier ou un dossier.

Ces paramètres sont donc facilement modifiables en cas de changement de dernière minute.

Si vous désirez inclure dans votre Package la modification de clés de registre, l'équipe Visual Web Développer donne une solution sur son blog. De même, ce billet explique comment inclure dans un Web Package le déploiement de composant COM.

Installation de Web Packages

Maintenant que notre Web Package est créée, il est temps de regarder comme fonctionne le déploiement de celui-ci. Il existe plusieurs manières de procéder :

• utiliser le Gestionnaire IIS ;
• utiliser le script de commande généré par Visual Studio 2010 ;
• utiliser MsDeploy.exe en ligne de commande ;
• utiliser le support Power Shell fourni par MsDeploy ;
• utiliser les API fournies par MsDeploy.

Commençons par regarder comment déployer notre site via le Gestionnaire IIS. Pour cet article, j'utilise IIS 7. Il faut avouer que c'est relativement simple d'utilisation : il suffit de cliquer sur le menu "Importer une application" comme le montre l'image ci-dessous :

Ce menu va nous ouvrir une fenêtre nous demandant de spécifier l'emplacement du package au format .zip. Une fois fait, IIS récapitulera le contenu de l'application, mais nous permettra également de choisir quels sont les éléments à importer ou non. Ci-dessous l'écran en question :

Comme on peut le voir sur la capture précédente, il existe des paramètres avancés que l'administrateur IIS peut spécifier lors du déploiement de l'application Web sur le serveur. Voici un aperçu des différents paramètres :

Le paramètre WhatIf est très utile, il permet de voir ce qui sera installé sur notre serveur sans qu'il y ait déploiement effectif. C'est une option précieuse pour vérifier le contenu d'un package.

Enfin, lors de la dernière étape précédant le déploiement effectif de l'application, IIS 7 nous permet de modifier si besoin le nom de l'application, le chemin physique du Virtual Directory, mais aussi la chaîne de connexion pour la base de données. Ces informations sont bien entendu extraites du package et sont telles que nous l'avons spécifié dans Visual Studio 2010 :

Ensuite, il suffit de lancer le déploiement et IIS nous résume dans la dernière étape si tout s'est correctement déroulé ou non, avec le détail des actions réalisées. Une fois le site déployé, il ne reste plus qu'à tester celui-ci via l'URL : http://localhost/WebApplicationBidon_deploy/.

Vous noterez que MsDeploy est parfaitement intégré à IIS 7. Cet article sur le déploiement d'application Web avec Visual Studio 2010 est surtout destiné aux développeurs, mais il est important de rappeler que les possibilités offertes par MsDeploy ne s'arrêtent pas là. MsDeploy permet aussi aux administrateurs IIS d'archiver et de restaurer des applications Web, de synchroniser une application avec un autre serveur. Pour plus d'informations sur le sujet, consultez le site officiel IIS ou Technet

Comme nous l'avons vu précédemment, il existe plusieurs méthodes pour installer un Web Package. Nous venons d'utiliser le Gestionnaire IIS, mais il est aussi possible d'utiliser le script de commande généré par Visual Studio 2010. Deux principales options sont à connaître : /T et /Y. La première option va vous permettre d'exécuter votre Package avec WhatIf à False. Ainsi l'installation ne sera pas effective mais vous permettra de tester le Package à l'avance. La deuxième option vous permet de lancer le déploiement effectif de l'application. Comme nous pouvons le voir ci-dessous, le script de commande ne fait qu'appeler MsDeploy.exe :

Un gros avantage qu'offre MsDeploy en mode de commande est que les appels à msdeploy.exe peuvent être scriptés, ce qui signifie qu'un déploiement multiserveur peut être entièrement automatisé et reproductible. Scripter ce type de déploiement signifie également que d'une seule machine, vous pouvez suivre un déploiement, voir les résultats de chaque script et afficher la synthèse sur votre bureau.

Création de Web Packages avec MSBuild

Après la création manuelle de Web Packages via Visual Studio 2010 (ou via le Gestionnaire IIS 7 pour exporter une application déjà déployée), il convient d'aborder la création de Packages avec MsBuild. Comme vous le savez surement, beaucoup d'entreprises ont mis en place de véritables usines automatisées pour la compilation, les tests unitaires, mais aussi le déploiement de leurs applications. On retrouve souvent ce type d'installation dans les équipes RAD (Rapid Application Development) dans le cadre de l'intégration continue. Les Web Packages couplés à MsBuild et CC.NET ou TFS montrent leur plein potentiel.

Pour ceux qui ne seraient pas familiers avec le modèle d'intégration continue, la lecture de cet article de Martin Fowler est plus que recommandée.

Les deux outils les plus populaires utilisés pour l'automatisation sont Nant et MsBuild. Nous nous focaliserons dans cet article sur MsBuild puisqu'il est utilisé constamment par Visual Studio 2010 pour la plupart des fonctionnalités de l'IDE. Pour vous convaincre, il suffit de regarder le contenu des fichiers projets (.Csproj ou .VbProj). Pour créer un Web Package avec MsBuild, là aussi la simplicité est au rendez-vous. Pour cela, il faut tout d'abord lancer le Visual Studio Command Prompt :

Si vous désirez inclure les paramètres IIS dans votre Package (comme c'est le cas dans notre exemple), pensez à lancer la fenêtre de commande en tant qu'administrateur

Pour lancer la création du package, la syntaxe est on ne peut plus simple : MsBUILD NomDuProjet.Csproj /T:Package (ou .VbProj si vous utilisez VB.NET). Ci-dessous le résultat de l'exécution de MsBuild :

Notez que MsBuild ne créera pas le Package si la compilation a échoué. Cela vous évitera, dans le cadre d'une automatisation, de vous retrouver avec une application déployée alors qu'elle ne fonctionne pas.

Pour aller un peu plus loin, il vous faudra consulter les articles dédiés à MsBuild. Mais il est utile de rappeler que par défaut, MsBuild utilise la configuration Debug lors de la compilation. Pour changer de configuration, il faut utiliser cette syntaxe : /P:Configuration=Release. Vous pouvez aussi indiquer l'endroit où vous souhaitez que le Web Package soit créé : MsBUILD NomDuProjet.Csproj /T:Package /P:Configuration=Release;PackageLocation="C:\Package". Pour plus d'informations sur MsBuild : MSDN.

Transformation de fichier Web.Config

Le déploiement d'applications, notamment Web, comporte toujours une phase de configuration. De nombreux paramètres sont propres à l'environnement d'exécution : on n'utilisera pas la même base de données ou le même compte applicatif sur l'environnement de production que sur celui de développement. Les fichiers Web.config comprennent généralement des paramètres qui doivent être différents selon l'environnement. Par exemple, vous pourriez avoir à effectuer les modifications suivantes lorsque vous déployez un fichier Web.config sur un serveur :

• changer une chaîne de connexion de base de données pour pointer vers la base de données du serveur de destination ;
• désactiver le débugage de l'environnement de production (pensez toujours à le faire, surtout pour les performances des applications ASP.NET !) ;
• supprimer les informations sensibles telles que les chaînes de connexion.

Pour gérer manuellement ces modifications à apporter au fichier Web.config lors d'un déploiement, vous pouvez effectuer les opérations suivantes:

• modifier le fichier Web.Config sur le serveur de destination chaque fois que le projet est déployé ;
• maintenir des versions séparées du fichier Web.config pour chaque environnement, et copier uniquement la version qui convient à l'environnement de destination lorsque vous déployez ;
• créer des fichiers XSLT pour transformer le fichier Web.config et appliquer les transformations une fois le projet déployé.

Après avoir été longtemps manuelles, les étapes citées plus haut sont devenues plus ou moins automatisées par des outils tiers. Cependant, tous ces outils ne sont pas forcément accessibles à tous les développeurs. Avec l'arrivée de Visual Studio 2010, les choses changent ! Il est désormais possible de définir des "profils" de Web.Config, et de les utiliser pour transformer automatiquement les Web.Config de l'application durant un déploiement. Ainsi on peut désormais générer automatiquement un fichier de config pour chaque environnement différent. Pour les projets d'applications Web, ASP.NET fournit des outils qui automatisent le processus de transformation des fichiers Web.Config quand ils sont déployés. Pour chaque environnement que vous souhaitez déployer, vous créez un fichier de transformation qui ne spécifie que les différences dans le fichier Web.Config pour cet environnement. L'arrivée de la transformation des fichiers Web.Config était très attendue des développeurs Web. Pour aider à mettre en place des déploiements (automatiques ou non) basés sur des lignes de commande, ce modèle de transformation est implémenté comme une tâche MsBuild.

Fonctionnement

Nous allons voir ici un bref aperçu du fonctionnement de la transformation des fichiers Web.Config. Le concept est relativement simple, habituellement vous avez un seul fichier Web.config pour une Web Application. C'est toujours le cas, mais vous pouvez désormais ajouter un fichier de transformation par serveur de destination désiré. Exemple: vous avez un serveur UAT et un serveur de PROD, vous pourrez alors ajouter à votre solution ces deux fichiers : Web.UAT.Config et Web.PROD.Config. Ensuite, le moteur de transformation XML se chargera de générer à partir de votre fichier Web.config original et transformation (UAT ou PROD), un fichier Web.Config transformé propre au serveur de destination choisi. Le schéma suivant résume ce principe :

Le fichier de transformation doit avoir le namespace Transformation spécifié dans le noeud de configuration comme indiqué ci-dessous :

Le namespace XML Document Transformation introduit deux nouveaux attributs qu'il est nécessaire de connaître pour utiliser la transformation de fichier Web.Config : l'attribut Transformation et l'attribut Locator. Ces deux namespaces portent bien leur nom :

• Transformation informe le moteur de transformation sur la façon de modifier le fichier Web.Config original pour un serveur de destination précis. On peut notamment à l'aide de cet attribut : remplacer, insérer ou supprimer un noeud. On peut également supprimer ou modifier des attributs;
• Locator informe le moteur sur le noeud exact pour lequel la transformation doit être appliquée. On peut utiliser XPath ou bien une condition pour trouver un noeud.

Exemple

Par défaut, pour une Web Application, Visual Studio 2010 va créer un fichier Web.Debug.Config et un fichier Web.Release.Config. Dans cet exemple, nous allons créer un fichier de transformation pour notre environnement UAT. Pour ce faire, il faut déjà créer une configuration propre à l'UAT, donc aller dans le menu Build puis sélectionner Configuration Manager :

Enfin, pour rajouter un fichier de transformation propre à l'UAT, un clic droit sur la Web Application dans Visual Studio 2010, puis "Add Config Transforms" comme le montre l'image suivante :

Pour notre exemple, nous allons transformer la chaîne de connexion ainsi qu'un AppSetting avec les valeurs propres à notre serveur UAT. Voici les parties qui nous intéressent dans le fichier Web.Config original :

Dans notre fichier de transformation Web.UAT.Config, nous allons utiliser les deux attributs Transformation et Locator pour modifier la chaîne "ApplicationServices", ainsi que l'AppSetting "MonAppSetting". Ci-dessous, le fichier de transformation utilisé pour faire cela. Vous remarquez que c'est simple à mettre en place.

Si nous analysons le code précédent, nous pouvons remarquer que la transformation utilisée ici est "Replace", celle-ci indique au moteur de transformation de remplacer le noeud entier. De même, la localisation utilisée ici est "Match", celle-ci informe le moteur de transformation que parmi toutes les nœuds “configuration/connectionStrings/add” que l'on trouve, il faut trouver dans Web.UAT.Config le nœud dont le nom correspond.

Notez également que le fichier de transformation contient uniquement les nœuds pour lesquels une transformation est désirée. Tout le reste est absent du fichier de transformation et sera repris directement dans le fichier Web.Config. Cela facilite grandement la tâche et nous évite de devoir tenir à jour tous les fichiers de transformation dès qu'une modification intervient dans le fichier Web.Config. Notez également que l'exemple indique comment remplacer une chaîne de connexion ou une AppSetting, mais vous pouvez faire bien plus : ajouter, renommer ou supprimer des éléments

Pour générer votre fichier Web.Config pour le déploiement, rien de plus simple : ouvrez le Visual Studio Command prompt, saisissez "MSBuild 'Path to Application project file (.Csproj/.VbProj)' /t:TransformWebConfig /p:Configuration=UAT" et validez pour obtenir ceci :

Une fois la transformation du fichier Web.Config pour l'environnement UAT finie, le fichier Web.Config résultant sera disponible dans le répertoire obj/UAT de votre projet. Vous pouvez ainsi l'utiliser pour déployer votre application sur l'environnement UAT.

Pour aller plus loin et connaître la syntaxe des différentes opérations offertes par la transformation de fichier Web.Config, je vous invite à consulter la documentation MSDN. On pourra citer notamment les opérations suivantes avec le namespace Locator :

• Condition : pour spécifier une expression XPath qui est combinée à l'expression XPath de l'élément courant. Les éléments qui correspondent à l'expression sont sélectionnés ;
• Match : pour sélectionner un ou des éléments dont la valeur correspond pour un ou plusieurs attributs. Si plusieurs attributs sont spécifiés, seuls les éléments dont tous les attributs correspondent sont sélectionnés ;
• XPath : pour spécifier une expression XPath qui sera appliqué au fichier Web.Config original. À différencier de "Condition" vu précédemment.

Les opérations suivantes sont proposées par le namespace Transform :

• Replace : pour remplacer le ou les éléments sélectionnés avec l'élément spécifié dans le fichier de transformation ;
• Insert : pour insérer l'élément qui est spécifié dans le fichier de transformation à la collection d'éléments de l'élément courant ;
• InsertBefore : même chose que Insert, mais pour une insertion avant l'élément courant dans la collection ;
• InsertAfter : même chose que Insert, mais pour une insertion après l'élément courant dans la collection ;
• Remove : pour supprimer l'élément sélectionné. Si plusieurs éléments sont sélectionnés, seul le premier est supprimé ;
• RemoveAll : pour supprimer tous les éléments sélectionnés ;
• RemoveAttributes : pour supprimer les attributs spécifiés pour l'élément sélectionné ;
• SetAttributes : pour assigner des valeurs aux attributs des éléments sélectionnés ;
• XSLT : pour appliquer un fichier XSLT aux éléments sélectionnés.

Comme vous pouvez le constater les namespaces Locator et Transform permettent, grâce aux différentes opérations et à l'utilisation d'expression XPath, de transformer facilement votre fichier Web.config.

Publication en un clic (One-Click Publishing)

Visual Studio propose désormais de s'interfacer directement avec les outils de gestion distante d'IIS, afin de déployer le site Web sur un serveur distant de façon automatique. Cette fonctionnalité ressemble à celle de publication qu'on retrouve dans les versions 2005 et 2008 de Visual Studio, cependant elle prépare en fait une vraie migration, incluant toutes les dépendances nécessaires. Il est de plus possible de publier sur plusieurs serveurs de façon simultanée, avec toutefois la limite de 50 profils de déploiement dans un projet, soit 50 serveurs publiés simultanément ! Avant de rentrer dans le vif du sujet, il est d'utile de cerner les avantages et inconvénients propres à l'utilisation de l'outil de publication et à celle de l'outil Copy Web Site. Choisir d'utiliser un de ces deux outils dépend de la façon dont vous comptez utiliser et maintenir votre site :

Comparaison des outils Copy Web Site et Publication

L'avantage le plus important de l'outil de publication par rapport à celui de copie est que, comme les Web Packages, il va nous permettre de réaliser des transformations sur le fichier Web.Config et de déployer une base de données.

Exemple avec Visual Studio 2010 et WebDeploy (MSDeploy)

Avant de commencer, il vous faut installer WebDeploy sur votre serveur IIS, si ce n'est pas fait. Vous pouvez le télécharger ici. Afin d'avoir toutes les options, il faut privilégier une installation complète. Une fois installé, vous devriez voir cette option supplémentaire dans le gestionnaire IIS :

Si vous cliquez sur cette option, vous pourrez dans le menu "Actions" à droite, ajouter une règle comme le montre la capture ci-dessus. Ainsi, il est possible de gérer de façon très complète les droits de déploiement et les types de déploiements sur votre serveur IIS. Pour plus de détails, se référer à la documentation IIS.

Une dernière chose avant de passer au déploiement de notre application avec Visual Studio 2010 : il faut savoir que VS utilise le Web Deployment Handler nommé MsDeploy.axd et stocké sur votre serveur IIS à cette adresse : https://NomDuServeurOuAdresseIP:8172/MSDeploy.axd. Il faut donc penser à activer les connexions distantes dans le gestionnaire IIS. Pour ce faire, sélectionnez le module Service de gestion (visible dans la première capture de ce chapitre). Vous obtenez ainsi l'écran suivant :

Il vous faut d'abord arrêter le server dans l'onglet de droite du gestionnaire, avant de pouvoir changer la configuration. Une fois fait, n'oubliez pas de redémarrer le service.

Passons maintenant au plus intéressant, à savoir déployer notre application WebApplicationBidon à l'aide de l'outil de publication dans Visual Studio 2010. Un simple clic droit, puis sélection de l'option "Publish..." vous affichera l'écran de l'outil :

Avec cet écran, nous pouvons publier à la volée notre site, mais aussi sauvegarder un profil de publication. Ainsi il est très facile (dans une limite de 50), de déployer notre site sur des serveurs différents sans avoir à paramétrer la publication à chaque release. Intéressons-nous de plus près aux différentes options :

• Nom du profil : il est possible de spécifier n'importe quel nom pour un profil. Mais prenez l'habitude dès le départ à ce qu'il soit explicite, notamment sur le serveur de destination ;
• Service URL : comme indiqué précédemment, c'est l'adresse du Web Deployment handler qu'utilisera Visual Studio lors du déploiement ;
• Site/Application Name : le nom du site et de l'application. Dans notre exemple : Web Default Site/WebApplicationBidonPublish (afin de ne pas écraser le site créé par notre Web Package précédent) ;
• Mark Folder as IIS Application on destination : cette option en ravira plus d'un. Si vous choisissez de publier un dossier à l'intérieur d'un site parent existant et que vous désirez avoir une gestion de la Session, du Cache et autres fonctionnalités pour ce sous-dossier, alors vous devrez convertir ce dossier dans une application IIS sous votre site parent. Ainsi, cocher cette case va le faire très facilement pour vous ;
• Allow untrusted certificates : le http sécurisé nécessite un certificat. Cette option est à décocher que si votre administrateur ou votre hébergeur vous le demande.
• User Name, Password : qu'est-ce que ça peut bien être ?

Pour terminer, un simple clic sur Publish et voilà notre application déployée sur notre serveur IIS.

Déploiement de Web Site

Étant donné l'utilisation beaucoup moins courante des Web Sites par rapport aux Web Applications, cette section ne fera que présenter les différentes possibilités offertes pour le déploiement de Web Site avec Visual Studio 2010, sans entrer dans les détails. Pour plus d'informations vous pouvez consulter la documentation MSDN qui s'enrichit chaque jour de nouveaux articles.

Utilisation d'un Web Deployment Projects

L'arrivée des Web Packages et de l'outil MsDeploy va sensiblement changer la donne pour le déploiement des applications Web. Cependant, il ne faut pas oublier le support des applications écrites sous Visual Studio 2005 et 2008, ni les développeurs ayant leurs habitudes. C'est pourquoi Microsoft a décidé d'ajouter le support des Web Deployment Projects dans Visual Studio 2010. Pour plus d'informations à ce sujet vous pouvez consulter le blog de l'équipe Visual Web Developer. Attention toutefois, l'outil n'est actuellement disponible qu'en version bêta.

Déploiement d'un Web Site avec l'outil Copy Web Site

Cette méthode de déploiement, dont nous avons vu les avantages et inconvénients précédemment, est assez similaire à l'utilisation d'un utilitaire FTP : elle vous permet de copier des fichiers du site Web actuel vers un autre site. Cependant il existe quelques différences entre un utilitaire FTP et le Copy Web Site :

• il vous permet de vous connecter et de copier des fichiers entre tout type de sites Web que vous pouvez créer dans Visual Studio, y compris les sites Web en localhost, les sites Web gérés par IIS, les sites Web FrontPage et les sites FTP ;
• il prend en charge une fonctionnalité de synchronisation, qui examine les fichiers sur les deux sites et permet de s'assurer que tous les fichiers sont à jour.

Vous pouvez utiliser l'outil de copie de site Web pour déplacer des fichiers de votre poste vers un serveur intermédiaire ou un serveur de production. Cet outil est particulièrement utile dans les situations où vous ne pouvez pas ouvrir les fichiers du site distant pour les modifier. Pour lancer l'outil, un simple clic droit sur le site web pour sélectionner le menu "Copy Web Site" suffit. Nous parlons bien entendu de Web Site uniquement, cet outil n'a pas lieu d'être pour une Web Application. L'écran représentant l'outil est semblable à un utilitaire FTP comme on peut le voir sur la capture suivante :

Pour aller plus loin vous trouvez un excellent tutoriel sur MSDN.

Déploiement d'un Web Site avec la commande Windows XCopy

L'outil XCopy en ligne de commande n'est plus à présenter car n'étant pas une nouveauté de la version 4.0 du Framework .NET ou de Visual Studio 2010. Le déploiement avec la commande Xcopy n'est ni plus ni moins qu'une simple copie des fichiers de votre application depuis l'emplacement de développement vers l'emplacement de production. Néanmoins, un rappel peut être utile, vous pouvez consulter ce tutoriel MSDN. Vous pouvez également taper en ligne de commande xcopy /? Pour avoir plus d'informations.

Déploiement de bases de données avec un Web Package

Visual Studio 2010 vous permet de déployer votre application avec toutes ses dépendances, y compris les dépendances de base de données sur SQL Server. En indiquant juste la chaîne de connexion de votre base de données Visual Studio 2010 va automatiquement scripter les données ainsi que le schéma de la base et l'ajouter au Web Package. Visual Studio 2010 vous permettra également de fournir des scripts SQL personnalisés et de les exécuter dans un ordre que vous aurez défini lors du déploiement sur le serveur de destination. Une fois votre base paramétrée dans le Web Package, avec vos paramètres IIS et le contenu Web, vous pouvez choisir de le déployer via le gestionnaire IIS sur un serveur de destination en fournissant une chaîne de connexion différente au moment de l'installation. Le schéma ci-dessous récapitule le contenu embarqué dans un Web Package pour le déploiement d'une base de données :

Déploiement d'une nouvelle base

Regardons l'écran Package/Publish SQL dans les propriétés du projet à déployer (notez bien qu'il concerne à la fois la création de Web Packages et l'outil de publication, car tous deux utilisent WebDeploy) :

Cet écran va nous permettre de spécifier les paramètres qui déterminent si et quels scripts seront exécutés lors du déploiement. Il est décomposé en deux parties : Database Entries (ci-dessus) et Database Entry Détails (ci-dessous). La première vous permet de sélectionner la base de données à déployer et la seconde permet de paramétrer celle-ci. Dans la partie Database Entries, vous pouvez ajouter ou supprimer une base de données à déployer, mais également utiliser la fonction "Import from Web.Config". Cette option, bien pratique, va parcourir les Connections Strings présentes dans votre Web.Config pour déterminer quelles sont les bases utilisées par votre application. Par défaut, pour les bases détectées, le suffixe "-Deployment" est ajouté.

Une fois la base ajoutée ou importée, il faut maintenant paramétrer son déploiement dans la partie Database Entry Details selon les paramètres disponibles détaillés ci-dessous.

• Connection string for destination database : vous permet de spécifier la chaîne de connexion à la base de données sur laquelle s'effectuera le déploiement. Notez l'avertissement de Visual Studio : il s'agit bien d'indiquer la base pour le déploiement, vous ne devez pas oublier de modifier la Connection String dans le fichier Web.Config (ou utiliser ce merveilleux outil qu'est la Transformation de fichier Web.Config, bien sûr).
• Pull data and/or schema from an existing database : par défaut cette case est cochée pour toute base importée du fichier Web.Config. Lorsqu'elle est cochée, elle permet aux scripts de la grille du dessous d'être automatiquement exécutés lors du déploiement de la base.
• Connection string for the source database : si l'option précédente est cochée, vous devez alors indiquer la Connection String pour la base de données source.
• Database scripting options : vous avez trois options disponibles : "Schema Only" pour générer automatiquement les scripts permettant de déployer uniquement la structure de la base, "Schema and Data" pour en plus de la structure, déployer les données de la base source sur la base de destination, enfin "Data Only" pour déployer uniquement les données. Si vous comptez déployer la base de donnés ASP.NET Membership par défaut, il vaut mieux vous tourner vers cet article MSDN.
• Database Scripts : vous permet de spécifier les scripts à exécuter lors du déploiement. Par défaut les scripts générés automatiquement sont sélectionnés. Mais vous pouvez en ajouter d'autres pour des opérations plus complexes.

Dans le cas de notre application WebApplicationBidon, un simple Import form Web.Config a suffi, ainsi que la saisie de la chaîne de connexion de destination. Lors du déploiement du Web Package, la base est bien déployée.

Déploiement d'une base existante

La section précédente décrit comme déployer une nouvelle base de données sur l'environnement de destination. Généralement, il s'agit plutôt de mettre à jour une base de données existante. La partie se complique donc un peu car on ne peut générer aussi facilement des scripts automatiques pour cela.

Si vous souhaitez supprimer la base de données de destination avant de déployer la base de données source, il faut ruser un peu. Éditez avec Visual Studio ou un éditeur de texte votre fichier .Csprof (ou .Vbproj). Dans la partie "PublishDatabaseSettings", ajoutez la property ScriptDropsFirst="True".

Pour déployer uniquement des modifications sur une base de données existante, rien de plus simple : il suffit de décocher dans la grid Database Scripts tous les scripts générés automatiquement. Ensuite à vous d'ajouter vos propres scripts SQL et dans l'ordre que vous souhaitez.

Publier son application sur la Web Application Gallery de Microsoft

La Windows Web Application Gallerypermet facilement d'explorer, de découvrir et d'installer les applications populaires ASP.Net et PHP (Eh oui !) sur Windows. Les utilisateurs peuvent parcourir et visualiser des applications pour différents types de sites Web, allant de galeries de photos, aux blogs, en passant par des sites e-commerce. La Web Application Gallery s'intègre à la Web Platform Installer, de sorte que lorsqu'un utilisateur clique sur "Install" pour une application, la plate-forme d'installation est lancée avec le contexte établi par la sélection de l'utilisateur. Cette galerie d'application, comme l'Apple Store, fournit un moyen simple et efficace pour les développeurs de toucher les centaines de millions d'utilisateurs de Windows. Lorsqu'une demande est acceptée par la galerie, l'application est ajoutée aux flux ATOM de la Web Application Gallery.

Publication sur la Web Application Gallery

La Web Application Gallery permet aux développeurs de déployer plus facilement des applications pour les utilisateurs Windows. La galerie ne stocke pas le code des applications, mais un Web Package. Ainsi, lorsqu'elle est couplée à la Web Platform Installer, un utilisateur pourra facilement déployer votre package sur son poste. Le développeur de l'application possède le point de distribution d'origine, que la Web Platform Installer utilise pour récupérer le package. Les informations affichées avec ce package sont fournies par le développeur durant le processus de soumission de la demande. La galerie contient à la fois des applications ASP.NET et des applications PHP qui suivent les principes de la Web App Gallery. Voici les quatre étapes que les développeurs doivent suivre afin d'avoir leur application disponible sur la galerie :

Étape 1: appliquer les principes de la Web App Gallery

Tout d'abord, les développeurs doivent examiner et appliquer les principes de la galerie à leur application. Ces principes reflètent les objectifs de celle-ci, à savoir de livrer une application de qualité, sécurisée et qui soit compatible sur toutes les plateformes supportées par la Web Platform Installer. Si vous avez des questions sur ces principes, un forum est prévu à cet effet.

Étape 2: utiliser les Bests Pratices

Ensuite, les développeurs peuvent visiter IIS.NET ou MSDN pour connaître les Best Pratices dans la conception et l'exécution d'applications sur IIS. L'idée est que le code soit robuste et sécurisé. Il est possible de poser également des questions à ce sujet sur le forum du site IIS.NET, notamment les développeurs php qui utilisent Apache (qui n'utilisent qu'Apache... certains connaissent bien IIS).

Etape 3: créer un Web package

Après les deux précédentes étapes, le développeur a simplement besoin de créer un Web Package afin de pouvoir distribuer son application. Exactement comme nous l'avons décrit plus haut avec la WepApplicationBidon.

Étape 4: soumettre une demande à la Web Application Gallery

Une fois le package créé et testé, il peut remplir le formulaire de soumission. Chaque demande est examinée afin de s'assurer qu'elle suit les principes de la galerie. Microsoft peut contacter le développeur de l'application dans le cadre de l'examen et aussi informer le développeur de l'application sur l'état de sa demande.

Dernière étape, une fois l'application disponible sur la galerie mais cette fois pour les utilisateurs. Ils peuvent utiliser la Web Platform Installer (qui pour rappel est un outil gratuit qui simplifie le téléchargement, l'installation et la mise à jour des composants de la plate-forme Web Microsoft, notamment IIS, SQL Server Express, le Framework .NET, Visual Web Developer, etc.).

Voilà, cet article sur le déploiement Web avec Visual Studio 2010 touche à sa fin. J'espère qu'elle vous aura été utile. N'hésitez pas à commenter les différents billets !