Déploiement Web avec Visual Studio 2010

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ée plusieurs Assemblies pour le site. Cela peut aller d'une Assembly par page ou par User-Control, ou une ou plusieurs Assemblies par dossier.

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.

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.

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.

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 :

Source Manifest est un simple fichier XML qui indique à MsDeploy quels 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.

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 versions 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.

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 bases 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ébogage, 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 package (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.

Regardons de plus près ce que Visual Studio a généré. Pour des raisons de lisibilité, certaines parties ont été retirées ou tronquées avec […] :

------ Build started: Project: WebApplicationBidon, Configuration: Debug Any CPU 
------ WebApplicationBidon -> Path\bin\WebApplicationBidon.dll
------ Publish started: Project: WebApplicationBidon, Configuration: Debug Any CPU 
------ Transformed Web.config using Web.Debug.config into obj\Debug\TransformWebConfig\transformed\Web.config.
Auto ConnectionString Transformed Account\Web.config into obj\Debug\CSAutoParameterize\transformed\Account\Web.config.
Auto ConnectionString Transformed obj\Debug\TransformWebConfig\transformed\Web.config into obj\Debug\CSAutoParameterize\transformed\Web.config.
Copying all files to temporary location below for package/publish:
obj\Debug\Package\PackageTmp.
Packaging into Path\obj\Debug\Package\WebApplicationBidon.zip.
Adding package (package).
Adding child appHostConfig [...]
Adding child application [...]
Adding child virtualDirectoryDefaults [...]
Adding child virtualDirectory [...]
Adding child appPoolConfig [...]
Adding child add [...]
Adding child processModel [...]
Adding child recycling [...]
Adding child periodicRestart [...]
Adding child schedule [...]
Adding child failure [...]
Adding child cpu [...]
Adding child contentPath (Path\obj\Debug\Package\PackageTmp).
Adding child dirPath (Path\obj\Debug\Package\PackageTmp\Account).
Adding child filePath (Path\obj\Debug\Package\PackageTmp\Account\ChangePassword.aspx).
Adding child setAcl (Path\obj\Debug\Package\PackageTmp).
Adding child setAcl (Path\obj\Debug\Package\PackageTmp).
Adding declared parameter 'IIS Web Application Name'.
Adding declared parameter 'IisVirtualDirectoryPhysicalPath'.
Adding declared parameter 'ApplicationServices-Web.config Connection String'.
Package "WebApplicationBidon.zip" is successfully created as single file at the following location:
file:///C:/Users/Nicolas Esprit/documents/visual%20studio%202010/Projects/WebApplicationBidon/WebApplicationBidon/obj/Debug/Package
To get the instructions on how to deploy the web package please visit the following link:
http://go.microsoft.com/fwlink/?LinkId=124618
Sample script for deploying this package is generated at the following location:
Path\obj\Debug\Package\WebApplicationBidon.deploy.cmd
For this sample script, you can change the deploy parameters by changing the following file: 
Path\obj\Debug\Package\WebApplicationBidon.SetParameters.xml
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Publish: 1 succeeded, 0 failed, 0 skipped ==========

Observons maintenant les fichiers qu'a généré 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.

Maintenant que notre Web Package est créé, 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 :

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

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 :

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.

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 :

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 :

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.

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 nœud 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 nœud. On peut également supprimer ou modifier des attributs ;
• Locator informe le moteur sur le nœud exact pour lequel la transformation doit être appliquée. On peut utiliser XPath ou bien une condition pour trouver un nœud.

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 nœud entier. De même, la localisation utilisée ici est « Match », celle-ci informe le moteur de transformation que parmi tous 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ée 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.

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 :

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.

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.

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.

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.

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ées 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.

La section précédente décrit comment 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.

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.

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).

Étape 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 plateforme Web Microsoft, notamment IIS, SQL Server Express, le Framework .NET, Visual Web Developer, etc.).