web-dev-qa-db-fra.com

Comment ajouter des transformations de configuration pour un fichier de configuration personnalisé dans Visual Studio?

Le projet sur lequel je travaille consiste à lire un grand nombre de points de terminaison de service (url) à partir d'un fichier de configuration. Comme la liste serait assez longue, j'ai décidé de les conserver dans un fichier de configuration personnalisé afin que mon fichier web.config reste propre et petit. J'ai inclus la section personnalisée sur mon site Web comme ci-dessous:

<mySection configSource="myConfig.config" />

Je fonctionne parfaitement bien.

Mais le problème de la transformation apparaît lors du déploiement du projet dans différents environnements. J'ai trois fichiers web.config:

Web.config

Web.Uat.config

Web.Release.config

Alors que la transformation web.config fonctionne, les transformations pour les fichiers de configuration personnalisés échouent lors du déploiement. 

Est-il possible de transformer le fichier de configuration personnalisé pendant le déploiement?

18
TejSoft

Visual Studio ne transforme que les fichiers web.config par défaut. 

Si vous avez besoin d’un fichier de configuration personnalisé avec transformation pour les environnements DEV, UAT, PROD, etc., essayez de: 

  1. Utilisez des extensions personnalisées pour Visual Studio telles que SlowCheetah - XML ​​Transforms pour la fonctionnalité d’aperçu de la transformation Config. 
  2. Ajoutez pour le projet de Nuget SlowCheetah pour fournir une transformation intégrée.

Un peu de détails: 

Ajouter une extension VS SlowCheetah à partir d'extensions et de mises à jour  Screen of Extensions and Updates

Faites un clic droit sur votre myconfig.config et choisissez Ajouter un formulaire:  Screen of Extensions and Updates

Dans chaque configuration définie, insérez vos propres règles de transormation comme ceci:

<services xmlns:xdt="http://schemas.Microsoft.com/XML-Document-Transform">
  <service name="WebApplication1.Services.Service2" xdt:Transform="Replace" xdt:Locator="Match(name)" >
    <endpoint address="http://localhost:57939/Services/DebugService" behaviorConfiguration="WebApplication1.Services.Service2AspNetAjaxBehavior"
      binding="webHttpBinding" contract="WebApplication1.Services.Service2" />
  </service>
</services>

J'espère que c'était utile

18
Michael

Je vais prolonger un peu la réponse d'Andoni Ripoll Jarauta.

Nous avons été confrontés à un problème similaire. Je souhaitais extraire les chaînes de connexion du fichier web.config pour limiter les conflits de fusion. Je voulais aussi créer une configuration "release" contenant des informations statiques lors de la publication.

...assez simple. Créez un fichier de configuration personnalisé, webdb.config, et mettez à jour le fichier web.config.

Ex . Web.config

<connectionStrings configSource="WebDB.config"/>

wedbdb.config (xml version = "1.0" est requis pour la transformation)

<?xml version="1.0" encoding="utf-8"?>
<connectionStrings>
</connectionStrings>

Ajouter ensuite les fichiers de transformation pour webdb.config

 enter image description here

Exemple WebDB.Debug.config:

<?xml version="1.0" encoding="utf-8"?>

<connectionStrings xdt:Transform="Replace" xmlns:xdt="http://schemas.Microsoft.com/XML-Document-Transform">
    <add name="PRRADDataContainer" connectionString="metadata=~/PRRADData.csdl|~/PRRADData.ssdl|~/PRRADData.msl;provider=System.Data.SqlClient;provider connection string=';Data Source=localhost;Initial Catalog=;User ID=;Password=;multipleactiveresultsets=True;App=EntityFramework';" providerName="System.Data.EntityClient" />
    <add name="MyConnectionString" connectionString="Data Source=localhost;Initial Catalog=;Persist Security Info=True;User ID=;Password=;" providerName="System.Data.SqlClient" />
</connectionStrings>

Exemple WebDB.Release.config:

<?xml version="1.0" encoding="utf-8"?>

<connectionStrings xdt:Transform="Replace" xmlns:xdt="http://schemas.Microsoft.com/XML-Document-Transform">
    <add name="PRRADDataContainer" connectionString="metadata=~/PRRADData.csdl|~/PRRADData.ssdl|~/PRRADData.msl;provider=System.Data.SqlClient;provider connection string=';Data Source=prod_server;Initial Catalog=;User ID=;Password=;multipleactiveresultsets=True;App=EntityFramework';" providerName="System.Data.EntityClient" />
    <add name="MyConnectionString" connectionString="Data Source=prod_server;Initial Catalog=;Persist Security Info=True;User ID=;Password=;" providerName="System.Data.SqlClient" />
</connectionStrings>

Ensuite, nous devons ajouter un événement après la construction. Ceci est créé en éditant simplement le fichier CSPROJ.

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterBuild">
    <TransformXml Source="WebDB.config" Transform="WebDB.$(Configuration).config" Destination="WebDB.config" />
</Target>

Maintenant, lorsque je lance localement, j'obtiens WebDB.Debug.config et lorsque je publie mon code, je dois simplement m'assurer de sélectionner "Release" comme source de configuration. Dans les deux cas, le fichier WebDB.config sera mis à jour avec le fichier correspondant lors de la création.

REMARQUE: assurez-vous de définir les propriétés webdb.config, webdb.debug.config et webdb.release.config sur "Ne pas copier" pour l'option "Copier dans le répertoire de sortie".

J'espère que cela t'aides!

4
spyder1329

J'utilisais SlowCheetah mais j'ai trouvé quelque chose que je pense plus élégant. Il suffit de demander à la génération de générer le fichier .config en fonction de la configuration de la construction. 

Si vous avez un app.Release.config dans votre projet (ou plusieurs autres selon vos besoins en matière de déploiement), il vous suffit de modifier le fichier du projet (celui du fichier .csproj si vous programmez en C #). Trouvez la fin de celui-ci, entre le dernier </ItemGroup> et le </Project>, et ajoutez:

  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
  <Target Name="AfterBuild">
    <PropertyGroup>
      <OutputTypeName>$(OutputType)</OutputTypeName>
      <OutputTypeName Condition="'$(OutputTypeName)'=='Library'">dll</OutputTypeName>
      <OutputTypeName Condition="'$(OutputTypeName)'=='Module'">dll</OutputTypeName>
      <OutputTypeName Condition="'$(OutputTypeName)'=='Winexe'">exe</OutputTypeName>
    </PropertyGroup>
    <TransformXml Source="Config\app.config" Transform="Config\app.$(Configuration).config" Destination="$(OutputPath)\$(AssemblyName).$(OutputTypeName).config" />
  </Target>
</Project>

Enregistrez et rechargez à partir de VisualStudio. Compilez en mode Publication et vérifiez le dossier bin/Publication sur votre fichier <MyProject>.config la transformation est terminée.

Cet exemple s’applique aux fichiers Exe et Dll et à toute version de VisualStudio, car includes this post help

1

Il existe une autre approche pour laquelle ne nécessite pas l'installation d'extensions ni l'utilisation d'événements de construction.

Supposons que vos configurations personnalisées ressemblent à ceci:

  • myConfig.config
  • myConfig.Uat.config
  • myConfig.Release.config

Ensuite, dans votre Web.config principal, vous avez ceci:

<mySection configSource="myConfig.config" />

Enfin, dans votre Web.Uat.config, vous ajoutez une transformation comme ceci:

<mySection configSource="myConfig.Uat.config" xdt:Transform="SetAttributes" />

Cela ne transforme pas le fichier myConfig.config, mais remplace plutôt le nom du fichier de configuration personnalisé à utiliser. Vous pouvez faire la même chose pour le Release et tous les autres environnements.

Votre myConfig.Uat.config ne doit pas contenir de transformations, mais une copie du fichier de configuration personnalisé de base, avec les valeurs appropriées pour l'environnement personnalisé.

L'inconvénient est que chaque fois que vous ajoutez quelque chose au fichier de configuration personnalisé de base, vous devez également ajouter des fichiers aux fichiers de configuration pour les autres env (même si la valeur doit être identique à travers les envs). Je considérerais donc simplement d'utiliser ces fichiers de configuration personnalisés pour les paramètres qui devraient être modifiés entre env.

0
Alisson