Utilisez Visual Studio web.config transform pour le débogage [dupliquer]

OK, avec la compréhension que web.debug.config & web.release.config sont en pour les colis/publier uniquement. J'ai trouvé un moyen de permettre ce que vous essayez de faire. J'ai blogué à ce sujet sur http://sedodream.com/2010/10/21/ASPNETWebProjectsWebdebugconfigWebreleaseconfig.aspx . Voici le résumé.

voyons maintenant comment nous pouvons permettre ce que la question asker veut faire.

pour récapituler, quand il construit sur un configuration particulière il veut qu'une transformation spécifique soit appliquée à web.config . Donc évidemment vous ne voulez pas maintenir un fichier web.config , parce qu'il va être réécrit.

Donc, ce que nous devons faire est de créer un nouveau fichier web.template.config , qui est juste une copie de web.config . Puis il suffit de supprimer web.config en utilisant Windows Explorer (ne pas supprimer en utilisant Visual Studio parce que nous ne voulons pas le supprimer du projet).

Note: Si vous utilisez un fournisseur de contrôle source qui est intégré dans Visual Studio alors vous voulez probablement supprimer web.configuration de la source de contrôle.

aussi avec ceci nous ne voulons pas utiliser web.debug.config ou web.release.config parce que ceux-ci ont déjà un rôle bien défini dans le Pipeline de publication Web donc nous ne voulons pas déranger cela. 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 que ce seront les transformations appliquées lorsque vous déboguez, ou exécuter votre application à partir de Visual Studio. Nous devons maintenant nous connecter au processus de construction/empaquetage/publication pour que tout cela soit connecté. Avec Web Application Projects (WAP) Il ya un point d'extensibilité que vous pouvez créer un dossier de projet dans le même dossier avec le nom {ProjectName}.wpp.targets où {ProjectName} est le nom du projet. Si ce fichier est sur le disque dans le même dossier que le WAP sera alors automatiquement importé dans le dossier 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 copiera toujours web.template.config en web.config sur la construction, même si vous ne déboguez pas votre application dans Visual Studio.

cela est nécessaire parce que nous avons encore besoin de soutenir le paquet/processus de publication de Visual Studio. Puis j'ai étendu la propriété PrepareForRunDependsOn pour inclure la cible UpdateWebConfigBeforeRun . Cette propriété est utilisée pour identifier la liste des cibles qui doivent être exécutées avant tout projet géré par Visual Studio.

dans cette cible , j'utilise la tâche TransformXml pour transformer web.template.config , en utilisant le bon fichier web.dev.***.config . Après cela, votre application démarre en utilisant la bonne web.config basée sur votre configuration de compilation. Après que j'ai une autre cible ExcludeCustomConfigTransformsFiles , que j'injecte dans le processus paquet/publication via l'attribut BeforeTargets=”ExcludeFilesFromPackage” . Cela est nécessaire parce que nous ne voulons pas que ces fichiers soient inclus lorsque la demande est empaquetée ou publiée. Donc, c'est vraiment tout là est à lui.

Pour expliquer le processus de publication un peu plus pour ce scénario. Lorsque vous empaquetez/publiez web.debug.config ou web.release.config , selon la configuration de construction, sera encore utilisé. Mais finalement le dossier qu'il est en train de transformer est web.template.config , de sorte que vous pourriez avoir à ajuster en fonction de ce que vous avez dans ce fichier. Des Questions Ou Des Commentaires?

Andrew est sur la bonne voie. Lorsque vous utilisez cette fonctionnalité, voici comment il a été conçu pour être utilisé.

web.config C'est le fichier de configuration dont les développeurs doivent utiliser localement. Idéalement, vous devriez obtenir cette standardisation. Par exemple, vous pouvez utiliser localhost pour des chaînes DB, et ce qui ne l'est pas. Vous devez vous efforcer pour cela de travailler sur les machines dev sans changements.

web.débogage.config Ce est la transformation qui est appliquée lorsque vous publiez votre application à l'environnement de stadification de développement. Cela apporterait des changements au web.config qui sont nécessaires pour l'environnement cible.

web.publier.config C'est la transformation qui s'applique lorsque vous publiez votre application dans l'environnement de "production". Évidemment, vous devrez faire attention avec les mots de passe en fonction de votre application/équipe.

le problème avec transformer le web.config que vous utilisez actuellement est qu'une transformation peut effectuer des actions destructrices pour le web.config. Par exemple, il peut supprimer des attributs a, Supprimer des éléments, etc.

vous pouvez simplement utiliser le web 'default'.config comme votre version de développement / débogage, puis le web.publier.config continuera bien sûr d'être la version de publication, puisque ses transformations sont appliquées lorsque vous publiez.

dans votre configuration de débogage, ajoutez une étape de post-construction, 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 circonstance où, pendant un certain temps, vous voulez connecter votre IDE à une base de données de test au lieu de votre base de données de développement. Bien que vous puissiez spécifier les chaînes de développement connect dans votre web par défaut.fichier de config, il serait vraiment agréable d'avoir un site Web.Test.fichier de configuration pour que lorsque vous changez votre configuration de construction en "Test", vous obteniez automatiquement les nouveaux paramètres pendant que vous êtes encore dans votre IDE.

l'alternative historique est de commenter un ensemble de chaînes de connexion pour un autre, mais ces nouvelles transformations config a tenu l'espoir de mettre enfin un enjeu au cœur de cette pratique laide. Bien qu'un fichier par défaut pour le développement et une transformation pour la publication puissent fonctionner la plupart du temps, en ajoutant une étape de post-construction pour transformer le web.le fichier de configuration est la réponse la plus complète à mon avis.