Vue d'ensemble du déploiement de projet d'application Web ASP.NET

Une fois que vous avez créé un projet d'application Web ASP.NET ou un projet de site Web ASP.NET dans Visual Studio 2010, vous déployez en général le projet sur un serveur Web sur lequel d'autres personnes peuvent accéder à votre application. Le déploiement implique en général davantage que la simple copie des fichiers de l'application d'un serveur à l'autre. Vous pouvez également avoir à effectuer des tâches supplémentaires, telles que les suivantes :

• Modification des paramètres du fichier Web.config qui doivent être différents dans l'environnement de destination, tels que les paramètres pour le débogage ou les chaînes de connexion de base de données.

• Propagation de données ou de structures de données dans les bases de données utilisées par l'application Web.

• Configuration des paramètres IIS sur l'ordinateur de destination, notamment le pool d'applications, la méthode d'authentification, l'autorisation ou non de l'exploration des répertoires et la gestion des erreurs.

• Installation des certificats de sécurité.

• Définition des valeurs dans le Registre de l'ordinateur de destination.

• Installation d'assemblys d'application dans le Global Assembly Cache (GAC) sur l'ordinateur de destination.

Une extension de Microsoft Internet Information Services (IIS), nommée Web Deploy, permet d'automatiser la plupart des tâches de déploiement. Visual Studio fournit des outils qui fonctionnent avec Web Deploy pour simplifier le déploiement d'un projet d'application Web.

Notes

Cette rubrique s'intéresse aux applications Web créés à l'aide d'un modèle de projet d'application Web.Vous pouvez également créer des applications Web à l'aide d'un modèle de projet de site Web.Pour plus d'informations sur le déploiement de projets de site Web, consultez Vue d'ensemble du déploiement de projet de site Web ASP.NET.

Cette rubrique contient les sections suivantes :

• Packages de déploiement Web

• Publication en un seul clic

• Scénarios d'entreprise

• Scénarios d'hébergement tiers

• Transformation d'un fichier Web.config

• Déploiement d'une base de données SQL Server

• Extension du canal de publication Web

Pour plus d'informations sur les rubriques abordées dans cette présentation, consultez Organigramme des informations relatives au déploiement ASP.NET.

Packages de déploiement Web

Vous pouvez déployer un projet d'application Web à l'aide de Visual Studio pour créer un package de déploiement Web et en installant le package sur le serveur de destination. Un package de déploiement est un fichier compressé (.zip) qui contient des informations requises pour configurer l'application dans IIS, copier des fichiers dans cette application et installer les ressources associées, comme des bases de données.

Vous pouvez créer le package de déploiement, puis l'installer séparément. Vous pouvez également utiliser une publication en un clic pour le déployer à distance au cours d'une seule étape. (Par défaut, la publication en un clic ne crée pas de package, mais vous pouvez spécifier qu'elle doit en créer un si vous le souhaitez.)

Outre les fichiers sources et binaires de l'application, un package de déploiement comprend généralement des fichiers contenant les types d'informations suivants :

• Paramètres IIS, tels que le pool d'applications, la méthode d'authentification, l'autorisation ou non de l'exploration des répertoires et la gestion des erreurs.

• Scripts de base de données utilisés pour propager des modifications vers les données de la base de données ou vers les structures de base de données.

• Paramètres qui contiennent des valeurs devant éventuellement être modifiées lorsque le package est installé, tels que les paramètres pour le débogage ou les chaînes de connexion.

Le processus de création du package Visual Studio est extensible. Voici quelques exemples d'informations que vous pouvez inclure dans un package, mais qui nécessitent des extensions personnalisées :

• Certificats de sécurité.

• Paramètres de Registre Windows.

• Assemblys (fichiers .dll) devant être installés dans le GAC sur l'ordinateur de destination.

Spécification des éléments à inclure dans un package de déploiement

Visual Studio utilise des paramètres que vous créez dans l'onglet Package/Publication Web de la page Propriétés du projet pour déterminer ce qui est inclus dans un package de déploiement. L'illustration suivante montre l'onglet Package/Publication Web.

Les paramètres relatifs à la base de données, qui affectent la création d'un package, sont entrés sous l'onglet Package/Publication SQL décrit ultérieurement dans cette rubrique.

Ces deux onglets vous permettent de mettre à jour les paramètres les plus utilisés. Les autres paramètres, qui sont utilisés moins souvent, sont stockés dans le fichier projet Visual Studio (.csproj ou .vbproj). Ils peuvent être changés en modifiant directement ce fichier.

Création d'un package de déploiement

Vous pouvez créer un package de différentes façons :

• Utilisation des outils dans Visual Studio.

• Utilisation de la commande MSBuild directement à partir de la ligne de commande.

• Utilisation indirecte de la commande MSBuild à partir de PowerShell ou de Team Build.

Installation d'un package de déploiement

Après avoir créé un package de déploiement, vous l'installez sur l'ordinateur de destination. Web Deploy utilise les informations contenues dans le package pour configurer IIS, installer les bases de données, créer des structures de dossiers et y copier les fichiers, et effectuer toute opération nécessaire au déploiement de l'application.

Vous pouvez installer un package des manières suivantes :

• Utilisez Web Deploy à partir de la ligne de commande.

• Utilisation d'un fichier .cmd créé par Visual Studio et contenant les commandes de Web Deploy qui installent le package. Les commandes de Web Deploy peuvent être longues et complexes. Ce fichier permet de simplifier l'installation d'un package à partir de la ligne de commande.

• Utilisation du Gestionnaire des services IIS.

• Utilisation de PowerShell pour exécuter des commandes de Web Deploy.

Lorsque vous créez un package, vous pouvez y inclure des paramètres. Il s'agit de paires nom-valeur auxquelles vous attribuez une valeur par défaut lorsque le package est créé, mais auxquelles une nouvelle valeur peut être attribuée lorsque le package est installé. Si vous utilisez le Gestionnaire des services IIS pour installer le package, les noms de paramètres sont affichés à l'aide de zones de texte afin que vous puissiez entrer de nouvelles valeurs. Si vous procédez à l'installation en utilisant Web Deploy à partir de la ligne de commande, vous pouvez spécifier des valeurs de paramètres dans un fichier XML.

Emplacement et contenu du dossier package

Par défaut, Visual Studio génère des packages de déploiement dans le dossier identifié par la propriété IntermediateOutputPath MSBuild. La propriété IntermediateOutputPath fait référence au dossier obj\Configuration du projet, comme indiqué dans l'illustration suivante de la fenêtre de l'Explorateur de solutions :

Les noms prédéfinis pour Configuration sont Debug (comme indiqué dans l'illustration précédente) et Release. Vous pouvez définir des configurations de build supplémentaires.

Le package est créé dans un dossier nommé Package. Le dossier Package contient les fichiers suivants :

• nomprojet.zip. Il s'agit du package de déploiement proprement dit.

• nomprojet.deploy.cmd. Il s'agit d'un fichier de commandes de ligne de commande qui appelle Web Deploy afin de simplifier l'installation du package à partir de la ligne de commande.

• nomprojet.SetParameters.xml. Ce fichier contient des paramètres qui sont passés à Web Deploy lorsque vous utilisez le fichier deploy.cmd pour installer le package. Pour chaque paramètre, une valeur par défaut est spécifiée. Cette dernière est déterminée par les paramètres du package Visual Studio. Par exemple, vous pouvez modifier ces valeurs si vous souhaitez installer l'application Web sur plusieurs serveurs mais utiliser des paramètres différents pour chaque serveur.

• nomprojet.SourceManifest.xml. Ce fichier contient les paramètres passés à Web Deploy par Visual Studio et utilisés par Web Deploy pour créer le package Web. Web Deploy a besoin de ce fichier uniquement pour créer le package. Il n'est pas utilisé lorsque le package est installé.

Si vous choisissez de ne pas créer le package en tant que fichier .zip, les fichiers qui auraient du être stockés dans le fichier .zip se situent dans un dossier nommé Archive. Dans ce cas, le premier nœud des noms des fichiers deploy.cmd, SetParameter.xml et SourceManifest.xml est « Archive » au lieu de nomprojet.

Les corrélations entre Visual Studio, Web Deploy et ces fichiers sont indiquées dans l'illustration suivante :

Publication en un seul clic

Vous pouvez également procéder au déploiement à distance à l'aide de la fonctionnalité de publication en un clic de Visual Studio. Dans ce cas, vous spécifiez, dans un profil de publication, le mode et l'emplacement de déploiement de l'application par Visual Studio. L'illustration suivante montre la boîte de dialogue Profil de la publication.

Si vous utilisez une publication en un clic pour déployer votre application auprès d'une société d'hébergement tiers, cette dernière vous fournira généralement les paramètres dont vous avez besoin pour la boîte de dialogue Profil de la publication.

Lorsque vous avez terminé de spécifier les paramètres de publication, vous pouvez cliquer sur le bouton Publier dans cette boîte de dialogue ou dans la barre d'outils Publication Web en un clic. Visual Studio déploie alors l'application sur l'ordinateur de destination. Lorsque vous cliquez sur le bouton Publier après le déploiement d'un projet d'application Web, Visual Studio redéploie uniquement les éléments modifiés.

Vous pouvez créer plusieurs profils afin de publier sur différents serveurs ou sur le même serveur avec des paramètres différents.

Scénarios d'entreprise

Dans un environnement d'entreprise, vous procédez généralement au déploiement à partir d'un ordinateur de développement dans un ou plusieurs environnements intermédiaires, tels qu'un serveur de test ou un serveur intermédiaire. Depuis l'un des environnements intermédiaires, vous déployez ensuite l'environnement de production.

Voici des scénarios classiques de déploiement initial depuis l'environnement de développement :

• Créez un package de déploiement à l'aide de Visual Studio et installez-le manuellement.

• Créez et installez le package de déploiement à l'aide d'un processus en ligne de commande. Cette opération s'effectue généralement en mode batch à partir d'un référentiel de contrôle de code source à l'aide de MSBuild.

• Utilisez la publication en un seul clic. Cette option est disponible si l'ordinateur de développement dispose de l'accès à distance à l'environnement de destination, si l'ordinateur de destination est installé pour la méthode de la publication que vous sélectionnez et si vous disposez des autorisations appropriées sur l'ordinateur de destination. Par défaut, la publication en un clic ne crée pas de package. Vous pouvez toutefois spécifier qu'un package doit être créé pour être utilisé en tant qu'archive ou sauvegarde.

Pour déployer d'un environnement à l'autre après le déploiement initial, vous pouvez utiliser le package créé pour le déploiement initial. Vous pouvez également utiliser Web Deploy pour créer un package sur l'ordinateur depuis lequel vous procédez au déploiement.

L'illustration suivante montre des scénarios d'entreprise typiques.

Scénarios d'hébergement tiers

Si vous faites appel à une société d'hébergement tiers et déployez directement depuis votre ordinateur de développement vers l'infrastructure de la société d'hébergement, vous disposez des options suivantes :

• Utilisez la publication en un clic Visual Studio.

• Créez un package et utilisez le Gestionnaire des services IIS pour l'installer à distance.

Au sein de la société d'hébergement, votre application peut figurer dans un environnement partagé ou sur des serveurs dédiés. Pour les applications hébergées dans des environnements partagés, votre capacité à configurer l'environnement est généralement très limitée. Par exemple, vous n'êtes généralement pas autorisé à modifier les paramètres IIS dans un environnement d'hébergement partagé.

L'illustration suivante montre des scénarios d'hébergement tiers typiques.

Transformation d'un fichier Web.config

Les fichiers Web.config incluent généralement des paramètres qui doivent être différents en fonction de l'environnement dans lequel l'application s'exécute. Par exemple, vous devrez peut-être apporter les modifications suivantes lors du déploiement d'un fichier Web.config sur un serveur de destination :

• Modification d'une chaîne de connexion de base de données de sorte qu'elle pointe vers l'emplacement de la base de données de production.

• Désactivation du débogage dans l'environnement de production.

• Suppression des informations sensibles, telles que les chaînes de connexion, si vous fournissez un package à un site communautaire, par exemple.

Pour gérer manuellement les modifications apportées à un fichier Web.config, vous pouvez effectuer les opérations suivantes :

• Modification du fichier Web.config sur le serveur de destination à chaque déploiement du projet.

• Maintien de versions distinctes du fichier Web.config pour chaque environnement (éventuellement dans des dossiers distincts ou en utilisant des noms distinctifs) et copie uniquement de la version appropriée sur l'environnement de destination lors du déploiement.

• Création de fichiers XSLT pour transformer le fichier Web.config et application des transformations lors du déploiement de l'application.

Pour les projets d'application Web, ASP.NET fournit des outils qui automatisent le processus de modification (transformation) des fichiers Web.config lors de leur déploiement. Pour chaque environnement dans lequel vous voulez procéder au déploiement, vous créez un fichier de transformation qui spécifie uniquement les différences dans le fichier Web.config pour cet environnement.

Le nom des fichiers de transformation inclut le nom de l'environnement de destination (nom de la configuration de build) sous la forme d'un nœud supplémentaire entre « Web » et « config ». Par exemple, le fichier de transformation pour la configuration de build Debug est Web.Debug.Config. La fenêtre Explorateur de solutions de Visual Studio regroupe automatiquement ces fichiers sous le fichier Web.config, comme indiqué dans l'illustration suivante :

Un fichier de transformation est un fichier XML qui spécifie la manière dont un fichier Web.config doit être modifié. Les fichiers de transformation utilisent des attributs XML conçus spécifiquement pour la transformation des fichiers Web.config en vue du déploiement. Par exemple, supposons que votre fichier Web.config contienne la section de chaîne de connexion suivante :

<connectionStrings>
  <add name="ApplicationServices"
      connectionString="[TestDatabase]" />
</connectionStrings>

Le fichier de transformation suivant spécifie que la chaîne de connexion nommée ApplicationServices est convertie automatiquement pour pointer vers une base de données de production lorsque l'application Web est déployée.

<?xml version="1.0"?>
<configuration xmlns:xdt="https://schemas.microsoft.com/XML-Document-Transform">
  <connectionStrings>
    <add name="ApplicationServices" 
        connectionString="[ProductionDatabase]" 
        xdt:Transform="Replace" xdt:Locator="Match(name)"/>
  </connectionStrings>
</configuration>

Dans l'exemple, la valeur d'attribut de Locator Match(name) spécifie que seul l'élément add portant le même nom (ApplicationServices) doit être modifié. La valeur d'attribut Transform Replace spécifie que le processus de déploiement doit remplacer l'élément add entier.

Déploiement d'une base de données SQL Server

Lorsque vous déployez une application Web qui utilise une base de données SQL Server, vous devrez peut-être propager des structures de données, des données ou les deux. Visual Studio peut créer automatiquement des scripts (fichiers .sql) pour effectuer ces opérations dans la base de données de destination et ces scripts peuvent être inclus dans le package Web. Vous pouvez également inclure des scripts SQL Server personnalisés et spécifier leur ordre d'exécution. Web Deploy exécute les scripts sur le serveur de destination lorsque le package est installé.

Spécifiez les options de déploiement SQL Server sous l'onglet Package/Publication SQL sur la page Propriétés du projet. L'illustration suivante montre l'onglet Package/Publication SQL.

Extension du canal de publication Web

Le canal de publication Web (WPP) est le processus utilisé par Visual Studio lorsque vous créez un package de déploiement ou utilisez une publication en un clic. Le travail exécuté dans le WPP est en fait exécuté par MSBuild et Web Deploy. C'est pour cette raison que les mêmes fonctionnalités sont disponibles dans Visual Studio ou lorsque vous utilisez des outils en ligne de commande pour procéder au déploiement.

Certains aspects du WPP peuvent être étendus en modifiant les fichiers XML qui contrôlent le comportement MSBuild. Voici des exemples de tâches que vous pouvez gérer en modifiant des fichiers XML :

• Exclusion de fichiers ou de dossiers d'application Web spécifiques du package.

• Précompilation de l'application Web avant la création du package.

• Installation d'assemblys d'application dans le GAC sur le serveur de destination.

• Mise à jour de clés de Registre sur le serveur de destination.

• Installation des certificats SSL sur le serveur de destination.

D'autres tâches nécessitent que vous étendiez à la fois MSBuild et Web Deploy. Supposez, par exemple, que votre application Web utilise MSMQ et que vous souhaitez automatiser le déploiement MSMQ. Pour cela, vous pouvez créer un fournisseur MSMQ pour Web Deploy et l'ajouter au WPP en modifiant les fichiers qui contrôlent MSBuild.

Web Deploy utilise le modèle de fournisseur .NET Framework. Chaque type d'informations devant être géré pour le déploiement est contrôlé par un fournisseur. Il existe, par exemple, un fournisseur pour les paramètres IIS, un fournisseur pour les bases de données SQL Server, un fournisseur pour le contenu Web tel que les fichiers .html et .aspx, etc.

Lorsque Web Deploy crée un package, il appelle chaque fournisseur pour rassembler des informations qui se rapportent à l'application Web qui sera déployée. Web Deploy appelle le fournisseur pour sérialiser les informations et les stocker dans les fichiers. Lorsque Web Deploy installe le package, le fournisseur lit les fichiers qui il a créé pour le package et désérialise les informations selon les besoins pour recréer les paramètres d'origine dans l'environnement de destination. Les fournisseurs doivent être en mesure de gérer des paramètres d'installation. Autrement dit, ils doivent être en mesure d'utiliser des valeurs fournies au moment de l'installation dans l'interface utilisateur Gestionnaire des services IIS ou dans un fichier Parameters.xml.

Les illustrations suivantes montrent le flux de données entre les informations d'une application Web, les fournisseurs de Web Deploy, l'API Web Deploy, un package de déploiement et un fichier de paramètres. Dans l'illustration, le fichier Parameters.xml est affiché en regard du fichier de package .zip pour illustrer son rôle. Le fichier Parameters.xml est toutefois réellement inclus dans le fichier de package .zip.

Ordinateur de développement

Serveur Web

Web Deploy prévoit des fournisseurs pour la plupart des types de ressources qui peuvent être associées à une application Web. Vous pouvez cependant créer un fournisseur personnalisé si aucun des fournisseurs intégrés n'est adapté à vos besoins. Pour obtenir la liste de fournisseurs disponibles, consultez Web Deploy Providerssur le site Web Microsoft TechNet.

L'illustration suivante montre une séquence typique d'étapes dans le WPP lorsque vous utilisez Web Deploy pour empaqueter ou publier. Il s'agit d'un WPP qui a été étendu par l'ajout des étapes suivantes :

• Exclusion de fichiers spécifiés.

• Précompilation de l'application Web.

• Déploiement d'assemblys GAC, d'assemblys COM et de clés de Registre.

• Déploiement de certificats SSL.

Si vous choisissez de procéder au déploiement à l'aide de la publication en un clic et d'une méthode autre que Web Deploy, vous pouvez uniquement étendre les parties du WPP qui ne s'appliquent pas à Web Deploy, comme indiqué dans l'illustration suivante :

Pour consulter des exemples qui décrivent la façon d'étendre le canal de publication Web pour des scénarios spécifiques, consultez les entrées suivantes sur le blog Visual Web Developer Team :

• How to extend the destination file to include registry settings for web deployment packages

• How to package and deploy COM components

• How to package .NET assemblies

Voir aussi

Concepts

Organigramme des informations relatives au déploiement ASP.NET