Utiliser la transformation web.config de Visual Studio pour le débogage
Duplicate possible:
Comment utiliser Web.debug.config dans le serveur de débogage de Visual Studio intégré?
Je veux utiliser la transformation Web.config qui fonctionne très bien pour publier également pour le débogage.
Lorsque je publie une application Web, Visual Studio transforme automatiquement le fichier Web.config en fonction de ma configuration currenctbuild. Comment puis-je demander à Visual Studio de faire de même lorsque je lance le débogage? Au début du débogage, il utilise simplement le fichier Web.config par défaut sans transformation.
Une idée?
OK, étant entendu que web.debug.config & web.release.config ne concerne que le package/la publication. J'ai mis au point un moyen d'activer ce que vous essayez de faire. J'ai blogué à ce sujet à l'adresse http://sedodream.com/2010/10/21/ASPNETWebProjectsWebdebugconfigWebreleaseconfig.aspx . Voici le résumé.
Voyons maintenant comment nous pouvons activer ce que l’interrogateur veut faire.
Pour récapituler, lorsqu'il construit sur une configuration particulière, il souhaite qu'une transformation spécifique soit appliquée à web.config. Donc, évidemment, vous ne voulez pas maintenir un web.config fichier, car il va être écrasé.
Nous devons donc créer un nouveau fichier web.template.config, qui n'est qu'une copie de web.config. Ensuite, supprimez simplement web.config à l'aide de l'Explorateur Windows (ne supprimez pas à l'aide de Visual Studio car nous ne souhaitons pas le supprimer du projet).
Remarque: Si vous utilisez un fournisseur de contrôle de source intégré à Visual Studio, vous souhaiterez probablement supprimer web.config du contrôle de source.
Aussi, avec cela, nous ne voulons pas utiliser web.debug.config ou web.release.config _ car ils ont déjà un rôle bien défini dans le pipeline de publication Web, nous ne voulons donc pas le perturber. Nous allons donc créer deux nouveaux fichiers, dans le même dossier que le projet et web.template.config, web.dev.debug.config et web.dev.release.config.
L'idée est qu'il s'agira des transformations appliquées lors du débogage ou de l'exécution de votre application à partir de Visual Studio. Maintenant, nous devons nous connecter au processus de construction/package/publication pour que tout soit câblé. Avec les projets d'application Web (WAP), vous pouvez créer un fichier de projet dans le même dossier portant le nom {ProjectName}.wpp.targets où {ProjectName} est le nom du projet. Si ce fichier se trouve sur le disque dans le même dossier que le WAP, il sera automatiquement importé dans le fichier de projet. J'ai donc créé ce fichier. Et j'ai placé le contenu suivant:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.Microsoft.com/developer/msbuild/2003">
<!-- Make sure web.config will be there even for package/publish -->
<Target Name="CopyWebTemplateConfig" BeforeTargets="Build">
<Copy SourceFiles="web.template.config"
DestinationFiles="web.config"/>
</Target>
<PropertyGroup>
<PrepareForRunDependsOn>
$(PrepareForRunDependsOn);
UpdateWebConfigBeforeRun;
</PrepareForRunDependsOn>
</PropertyGroup>
<!-- This target will run right before you run your app in Visual Studio -->
<Target Name="UpdateWebConfigBeforeRun">
<Message Text="Configuration: $(Configuration): web.dev.$(Configuration).config"/>
<TransformXml Source="web.template.config"
Transform="web.dev.$(Configuration).config"
Destination="web.config" />
</Target>
<!-- Exclude the config template files from the created package -->
<Target Name="ExcludeCustomConfigTransformFiles" BeforeTargets="ExcludeFilesFromPackage">
<ItemGroup>
<ExcludeFromPackageFiles Include="web.template.config;web.dev.*.config"/>
</ItemGroup>
<Message Text="ExcludeFromPackageFiles: @(ExcludeFromPackageFiles)" Importance="high"/>
</Target>
</Project>
Laissez-moi vous expliquer un peu. J'ai créé la cible CopyWebTemplateConfig qui copie toujours web.template.config à web.config sur la construction, même si vous ne déboguez pas votre application dans Visual Studio.
Cela est nécessaire car nous devons toujours prendre en charge le processus de package/publication de Visual Studio. Ensuite, j'ai étendu la propriété PrepareForRunDependsOn pour inclure la cible UpdateWebConfigBeforeRun. Cette propriété est utilisée pour identifier la liste des cibles à exécuter avant l'exécution de tout projet géré à partir de Visual Studio.
Dans cette cible, j'utilise la tâche TransformXml pour transformer web.template.config, en utilisant le bon web.dev.***.config fichier. Après cela, votre application démarre avec le bon web.config basé sur votre configuration de construction. Après cela, j’ai une autre cible ExcludeCustomConfigTransformsFiles, que j’injecte dans le processus de paquet/publication via l’attribut BeforeTargets=”ExcludeFilesFromPackage”. Cela est nécessaire car nous ne voulons pas que ces fichiers soient inclus lorsque l'application est empaquetée ou publiée. C'est donc tout ce qu'il y a à faire.
Pour expliquer le processus de package/publication un peu plus pour ce scénario. Quand vous empaquetez/publiez web.debug.config ou web.release.config, selon la configuration de la construction, sera toujours utilisé. Mais finalement, le fichier en cours de transformation est web.template.config, vous devrez peut-être ajuster en fonction de ce que vous avez dans ce fichier. Questions/Commentaires?
Andrew est sur le bon chemin. Lorsque vous utilisez cette fonctionnalité, voici comment elle a été conçue pour être utilisée.
web.config Ceci est le fichier de configuration que les développeurs doivent utiliser localement. Idéalement, vous devriez obtenir ceci pour qu'il soit normalisé. Par exemple, vous pouvez utiliser localhost pour les chaînes de base de données, et tout le reste. Vous devez vous efforcer de faire en sorte que cela fonctionne sur les machines de développement sans modifications.
web.debug.config Il s'agit de la transformation appliquée lorsque vous publiez votre application dans l'environnement de transfert de développement. Cela apporterait les modifications à web.config requises pour l'environnement cible.
web.release.config Il s'agit de la transformation appliquée lorsque vous publiez votre application dans l'environnement "de production". Évidemment, vous devrez faire attention aux mots de passe en fonction de votre application/équipe.
Le problème avec la transformation du web.config que vous exécutez actuellement est qu’une transformation peut effectuer des actions destructrices sur le web.config. Par exemple, il peut supprimer un attribut, supprimer des éléments, etc.
Vous pouvez simplement utiliser le fichier Web.config 'par défaut' comme version de développement/débogage, puis le fichier web.release.config continuera bien entendu à être la version finale, car ses transformations sont appliquées lors de la publication.
Dans votre configuration de débogage, ajoutez une étape post-génération et utilisez-la pour remplacer/transformer votre web.config
Bien que je convienne que l'approche la plus simple est généralement la meilleure, je peux facilement imaginer une situation dans laquelle vous souhaitez pendant un certain temps connecter votre IDE à une base de données de test plutôt qu'à votre base de développement. Bien que vous puissiez spécifier les chaînes de connexion de développement dans votre fichier web.config par défaut, il serait vraiment agréable d’avoir un fichier Web.Test.config afin que, lorsque vous permutez votre configuration de construction à "Test", vous obteniez automatiquement les nouveaux paramètres. tout en restant dans votre IDE.
L’alternative historique consiste à commenter un ensemble de chaînes de connexion entre elles, mais cette nouvelle config de transformation a laissé espérer que l’on pourrait enfin mettre un pieu au cœur de cette pratique laide. Bien qu'un fichier par défaut pour le développement et une transformation pour publication puissent fonctionner la plupart du temps, l'ajout d'une étape post-génération pour transformer le fichier web.config est la réponse la plus complète à mon avis.