Déploiement d’une application web ASP.NET avec SQL Server Compact à l’aide de Visual Studio ou Visual Web Developer : Transformations de fichiers Web.Config - 3 sur 12
par Tom Dykstra
Télécharger le projet de démarrage
Cette série de tutoriels vous montre comment déployer (publier) un projet d’application web ASP.NET qui inclut une base de données SQL Server Compact à l’aide de Visual Studio 2012 RC ou Visual Studio Express 2012 RC pour web. Vous pouvez également utiliser Visual Studio 2010 si vous installez la mise à jour de publication web. Pour une présentation de la série, consultez le premier didacticiel de la série.
Pour obtenir un didacticiel montrant les fonctionnalités de déploiement introduites après la version RC de Visual Studio 2012, montre comment déployer des éditions SQL Server autres que SQL Server Compact et comment déployer sur Azure App Service Web Apps, consultez ASP.NET déploiement web à l’aide de Visual Studio.
Vue d’ensemble
Ce tutoriel vous montre comment automatiser le processus de modification du fichier Web.config lorsque vous le déployez dans différents environnements de destination. La plupart des applications ont des paramètres dans le fichier Web.config qui doivent être différents lorsque l’application est déployée. L’automatisation du processus d’exécution de ces modifications vous empêche de devoir les faire manuellement chaque fois que vous déployez, ce qui serait fastidieux et sujette à des erreurs.
Rappel : Si vous recevez un message d’erreur ou qu’un message d’erreur ne fonctionne pas au fur et à mesure que vous parcourez le tutoriel, veillez à consulter la page de résolution des problèmes.
Transformations Web.config et paramètres de déploiement web
Il existe deux façons d’automatiser le processus de modification des paramètres de fichier Web.config : transformations Web.config et paramètres Web Deploy. Un fichier de transformation Web.config contient le balisage XML qui spécifie comment modifier le fichier Web.config lors du déploiement. Vous pouvez spécifier différentes modifications pour des configurations de build spécifiques et pour des profils de publication spécifiques. Les configurations de build par défaut sont Debug et Release, et vous pouvez créer des configurations de build personnalisées. Un profil de publication correspond généralement à un environnement de destination. (Vous en apprendrez davantage sur les profils de publication dans le Déploiement sur IIS en tant que didacticiel sur l’environnement de test.)
Les paramètres web Deploy peuvent être utilisés pour spécifier de nombreux types de paramètres qui doivent être configurés pendant le déploiement, y compris les paramètres trouvés dans les fichiers Web.config . Lorsqu’ils sont utilisés pour spécifier les modifications de fichier Web.config , les paramètres Web Deploy sont plus complexes à configurer, mais ils sont utiles lorsque vous ne connaissez pas la valeur à définir tant que vous n’avez pas déployé. Par exemple, dans un environnement d’entreprise, vous pouvez créer un package de déploiement et le donner à une personne du service informatique pour l’installer en production, et cette personne doit être en mesure d’entrer des chaîne de connexion ou des mots de passe que vous ne connaissez pas.
Pour le scénario décrit par ce tutoriel, vous savez que tout ce qui doit être fait dans le fichier Web.config , vous n’avez donc pas besoin d’utiliser les paramètres Web Deploy. Vous allez configurer certaines transformations qui diffèrent selon la configuration de build utilisée, et certaines qui diffèrent selon le profil de publication utilisé.
Création de fichiers de transformation pour les profils de publication
Dans Explorateur de solutions, développez Web.config pour afficher les fichiers de transformation Web.Debug.config et Web.Release.config créés par défaut pour les deux configurations de build par défaut.
Vous pouvez créer des fichiers de transformation pour des configurations de build personnalisées en cliquant avec le bouton droit sur le fichier Web.config et en choisissant Ajouter des transformations de configuration dans le menu contextuel, mais pour ce didacticiel, vous n’avez pas besoin de le faire.
Vous avez besoin de deux fichiers de transformation supplémentaires pour la configuration des modifications liées à la destination du déploiement plutôt qu’à la configuration de build. Un exemple classique de ce type de paramètre est un point de terminaison WCF différent pour le test et la production. Dans les didacticiels ultérieurs, vous allez créer des profils de publication nommés Test et Production. Vous avez donc besoin d’un fichier Web.Test.config et d’un fichier Web.Production.config .
Les fichiers de transformation liés aux profils de publication doivent être créés manuellement. Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet ContosoUniversity et sélectionnez Ouvrir le dossier dans l’Explorateur Windows.
Dans l’Explorateur Windows, sélectionnez le fichier Web.Release.config , copiez le fichier, puis collez deux copies. Renommez ces copies Web.Production.config et Web.Test.config, puis fermez l’Explorateur Windows.
Dans Explorateur de solutions, cliquez sur Actualiser pour afficher les nouveaux fichiers.
Sélectionnez les nouveaux fichiers, cliquez avec le bouton droit, puis cliquez sur Inclure dans Project dans le menu contextuel.
Pour empêcher le déploiement de ces fichiers, sélectionnez-les dans Explorateur de solutions, puis, dans la fenêtre Propriétés, remplacez la propriété Action de génération du contenu par Aucun. (Les fichiers de transformation basés sur des configurations de build sont automatiquement empêchés de déployer.)
Vous êtes maintenant prêt à entrer des transformations Web.config dans les fichiers de transformation Web.config .
Limitation de l’accès au journal des erreurs aux administrateurs
En cas d’erreur pendant l’exécution de l’application, l’application affiche une page d’erreur générique à la place de la page d’erreur générée par le système et utilise le package NuGet Elmah pour la journalisation et la création de rapports d’erreurs. L’élément customErrors du fichier Web.config spécifie la page d’erreur :
<customErrors mode="RemoteOnly" defaultRedirect="~/GenericErrorPage.aspx">
<error statusCode="404" redirect="~/GenericErrorPage.aspx" />
</customErrors>
Pour afficher la page d’erreur, remplacez temporairement l’attribut mode de l’élément customErrors par « RemoteOnly » par « On » et exécutez l’application à partir de Visual Studio. Provoquez une erreur en demandant une URL non valide, telle que Studentsxxx.aspx. Au lieu d’une page d’erreur « page introuvable » générée par IIS, vous voyez la page GenericErrorPage.aspx .
Pour afficher le journal des erreurs, remplacez tout dans l’URL après le numéro de port par elmah.axd (par exemple dans la capture d’écran), http://localhost:51130/elmah.axdpuis appuyez sur Entrée :
N’oubliez pas de définir l’élément customErrors en mode « RemoteOnly » lorsque vous avez terminé.
Sur votre ordinateur de développement, il est pratique d’autoriser l’accès gratuit à la page du journal des erreurs, mais en production qui serait un risque de sécurité. Pour le site de production, vous pouvez ajouter une règle d’autorisation qui limite l’accès au journal des erreurs uniquement aux administrateurs en configurant une transformation dans le fichier Web.Production.config .
Ouvrez Web.Production.config et ajoutez un nouvel location élément immédiatement après la balise d’ouverture configuration , comme illustré ici. (Assurez-vous que vous ajoutez uniquement l’élément location et non le balisage environnant qui est affiché ici uniquement pour fournir un contexte.)
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<location path="elmah.axd" xdt:Transform="Insert">
<system.web>
<authorization>
<allow roles="Administrator" />
<deny users="*" />
</authorization>
</system.web>
</location>
</configuration>
La Transform valeur d’attribut de « Insert » entraîne l’ajout de cet location élément en tant que frère à tous les éléments existants location dans le fichier Web.config . (Il existe déjà un location élément qui spécifie des règles d’autorisation pour la page Mettre à jour les crédits .) Lorsque vous testez le site de production après le déploiement, vous allez tester pour vérifier que cette règle d’autorisation est effective.
Vous n’avez pas besoin de restreindre l’accès au journal des erreurs dans l’environnement de test. Vous n’avez donc pas besoin d’ajouter ce code au fichier Web.Test.config .
Remarque
Note de sécurité Ne jamais afficher les détails d’erreur au public dans une application de production ou stocker ces informations dans un emplacement public. Les attaquants peuvent utiliser des informations d’erreur pour détecter des vulnérabilités dans un site. Si vous utilisez ELMAH dans votre propre application, veillez à examiner les façons dont ELMAH peut être configuré pour réduire les risques de sécurité. L’exemple ELMAH de ce didacticiel ne doit pas être considéré comme une configuration recommandée. Il s’agit d’un exemple qui a été choisi pour illustrer comment gérer un dossier dans lequel l’application doit pouvoir créer des fichiers.
Définition d’un indicateur d’environnement
Un scénario courant consiste à avoir des paramètres de fichier Web.config qui doivent être différents dans chaque environnement sur lequel vous déployez. Par exemple, une application qui appelle un service WCF peut avoir besoin d’un autre point de terminaison dans les environnements de test et de production. L’application Contoso University inclut également un paramètre de ce type. Ce paramètre contrôle un indicateur visible sur les pages d’un site qui vous indique l’environnement dans lequel vous êtes, tel que le développement, le test ou la production. La valeur de paramètre détermine si l’application ajoute « (Dev) » ou « (Test) » au titre principal de la page maître Site.Master :
L’indicateur d’environnement est omis lorsque l’application est en cours d’exécution en production.
Les pages web contoso University lisent une valeur définie dans appSettings le fichier Web.config pour déterminer l’environnement dans lequel l’application s’exécute :
<appSettings>
<add key="Environment" value="Dev" />
</appSettings>
La valeur doit être « Test » dans l’environnement de test et « Prod » dans l’environnement de production.
Ouvrez Web.Production.config et ajoutez un appSettings élément immédiatement avant la balise d’ouverture de l’élément location que vous avez ajouté précédemment :
<appSettings>
<add key="Environment" value="Prod" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>
La xdt:Transform valeur d’attribut « SetAttributes » indique que l’objectif de cette transformation est de modifier les valeurs d’attribut d’un élément existant dans le fichier Web.config . La xdt:Locator valeur d’attribut « Match(key) » indique que l’élément à modifier est celui dont key l’attribut correspond à l’attribut key spécifié ici. Le seul autre attribut de l’élément add est value, et c’est ce qui sera modifié dans le fichier Web.config déployé. Ce code entraîne la value définition de l’attribut de l’élément Environment appSettings sur « Prod » dans le fichier Web.config déployé en production.
Ensuite, appliquez la même modification au fichier Web.Test.config , à l’exception de la value valeur « Test » au lieu de « Prod ». Lorsque vous avez terminé, la appSettings section dans Web.Test.config ressemble à l’exemple suivant :
<appSettings>
<add key="Environment" value="Test" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>
Désactivation du mode débogage
Pour une build Release, vous ne souhaitez pas que le débogage soit activé quel que soit l’environnement sur lequel vous effectuez le déploiement. Par défaut, le fichier de transformation Web.Release.config est créé automatiquement avec du code qui supprime l’attribut debug de l’élément compilation :
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>
L’attribut Transform entraîne l’omission de l’attribut debug à partir du fichier Web.config déployé chaque fois que vous déployez une build Release.
Cette même transformation se trouve dans les fichiers de transformation test et production, car vous les avez créés en copiant le fichier de transformation Release. Vous n’avez pas besoin qu’elle soit dupliquée, donc ouvrez chacun de ces fichiers, supprimez l’élément de compilation et enregistrez et fermez chaque fichier.
Définition des chaînes de connexion
Dans la plupart des cas, vous n’avez pas besoin de configurer chaîne de connexion transformations, car vous pouvez spécifier des chaîne de connexion dans le profil de publication. Toutefois, il existe une exception lorsque vous déployez une base de données SQL Server Compact et que vous utilisez Migrations Entity Framework Code First pour mettre à jour la base de données sur le serveur de destination. Pour ce scénario, vous devez spécifier une chaîne de connexion supplémentaire qui sera utilisée sur le serveur pour mettre à jour le schéma de base de données. Pour configurer cette transformation, ajoutez un élément connectionStrings> immédiatement après la balise de configuration> d’ouverture <dans les fichiers de transformation Web.Test.config et Web.Production.config :<
<connectionStrings>
<add name="SchoolContext_DatabasePublish" connectionString="Data Source=|DataDirectory|School-Prod.sdf" providerName="System.Data.SqlServerCe.4.0" xdt:Transform="Insert"/>
</connectionStrings>
L’attribut Transform spécifie que cette chaîne de connexion sera ajoutée à l’élément connectionStrings dans le fichier Web.config déployé. (Le processus de publication crée cette chaîne de connexion supplémentaire automatiquement pour vous s’il n’existe pas, mais par défaut, l’attribut providerName est défini System.Data.SqlClientsur , ce qui ne fonctionne pas pour SQL Server Compact. En ajoutant manuellement le chaîne de connexion, vous empêchez le processus de déploiement de créer un élément chaîne de connexion avec le nom de fournisseur incorrect.)
Vous avez maintenant spécifié toutes les transformations Web.config dont vous avez besoin pour déployer l’application Contoso University pour tester et produire. Dans le tutoriel suivant, vous allez vous occuper des tâches de configuration de déploiement qui nécessitent la définition des propriétés du projet.
Informations supplémentaires
Pour plus d’informations sur les rubriques abordées par ce didacticiel, consultez le scénario de transformation Web.config dans ASP.NET Mappage de contenu de déploiement.