web-dev-qa-db-fra.com

Comment publier des appsettings spécifiques à l'environnement dans une application .Net?

J'ai 3 fichiers appsettings spécifiques à l'environnement dans mon application .Net Core

 enter image description here

dans project.json j'ai configuré publishOptions comme ceci. (basé sur suggestion ici )

"publishOptions": {
    "include": [
      "wwwroot",      
      "appsettings.development.json",
      "appsettings.staging.json",
      "appsettings.production.json",
      "web.config"
    ]
  },

J'ai 3 classes de démarrage correspondantes qui utilisent la variable appsetings appropriée en fonction de l'environnement

var builder = new ConfigurationBuilder()
    .SetBasePath(env.ContentRootPath)
    .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: false, reloadOnChange: true);

Cependant, lorsque je publie l'application, tous les fichiers de 3 appsettings se terminent dans tous les environnements. Comment publier un fichier de définition d'application spécifique à l'environnement?

asp.net-core.net-coreasp.net-core-1.0coreclr
17
LP13

Une solution possible consiste à exécuter des scripts/commandes prépublish ou post-publics, par exemple en exécutant une tâche gulp exécutant dotnet publish-iis (vous pouvez également utiliser une tâche dans la section prepublish de scripts pour copier les fichiers avant leur publication.

Ajoutez ceci à votre projet.json:

"scripts": {
  "postpublish": [ "gulp cleanconfig", "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}

Vous pouvez également exécuter une commande cmd ou Shell ici. Mais en réalité, il ne devrait y avoir aucune raison pour laquelle vous voudriez le faire en premier lieu, envoyez simplement les 3 fichiers appconfig, car c’est-à-dire Azure App Service, vous pouvez changer de mode en fonction des variables d’environnement régulées via le Azure Portal et lors de la publication, les emplacements de transfert et de production seront simplement échangés, mais les variables d'environnement restent.

Cependant, vous ne devriez pas stocker de secrets dans le fichier appsettings.json (ce que je suppose que vous faites et la raison pour laquelle vous souhaitez supprimer les fichiers). Utilisez plutôt les "secrets de l'utilisateur" pour les variables de développement et environnementales afin de définir les chaînes de connexion, etc. pour la production. Fonctionne comme un charme, en particulier avec Azure App Services et les conteneurs Docker.

3
Tseng

Dans VS2017 Ajout de plusieurs environnements

pas cliquez avec le bouton droit sur projet -> Ajouter -> NewItem - sélectionnez un fichier json - écrivez le nom du fichier sous le nom "appsettings.staging.json" ou "appsettings.production.json".

Ajouter un fichier appsettings.staging.json

La sortie ressemble à

2
Balaji Sadhu

Si quelqu'un d'autre se demande comment utiliser différentes configurations d'applications pour plusieurs environnements, voici une solution possible.

dotnet publish --configuration [Debug|Release] copiera le fichier appsettings.json approprié dans le dossier de publication si *.csproj possède une logique conditionnelle pour ces fichiers:

  • Premier dans le fichier de profil de publication .pubxml (se trouve dans Properties-> PublishProfiles de Visual Studio), désactivez l'inclusion par défaut de tous les fichiers de contenu
<PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <EnableDefaultContentItems>false</EnableDefaultContentItems>
</PropertyGroup>
  • Puis spécifiez la logique de débogage/libération conditionnelle
<Choose>
    <When Condition="'$(Configuration)' == 'Debug'">
      <ItemGroup>
        <None Include="appsettings.json" CopyToOutputDirectory="Always" CopyToPublishDirectory="Always" />
        <None Include="appsettings.prod.json" CopyToOutputDirectory="Never" CopyToPublishDirectory="Never" />
      </ItemGroup>
    </When>
    <When Condition="'$(Configuration)' == 'Release'">
      <ItemGroup>
        <None Include="appsettings.json" CopyToOutputDirectory="Never" CopyToPublishDirectory="Never" />
        <None Include="appsettings.prod.json" CopyToOutputDirectory="Always" CopyToPublishDirectory="Always" />
      </ItemGroup>
    </When>
</Choose>
  • Enfin, dans Startup.cs, essayez de charger les deux fichiers
public Startup(IHostingEnvironment env)
{
    var builder = new ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile($"appsettings.prod.json", optional: true, reloadOnChange: true)
        .AddJsonFile($"appsettings.json", optional: true, reloadOnChange: true)
        .AddEnvironmentVariables();

    Configuration = builder.Build();
}

J'espère que cette solution a été utile.

1
Ben

Vous devez réellement ajouter les variables d’environnement, selon le tutoriel officiel :

var builder = new ConfigurationBuilder()
    .SetBasePath(env.ContentRootPath)
    .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: false, reloadOnChange: true)
    // do not forget to add environment variables to your config!
    .AddEnvironmentVariables();
1
VMAtm

Le moyen le plus simple que j’ai trouvé jusqu’à présent consiste à déployer tous les fichiers de configuration, puis à en supprimer d’autres une fois le déploiement terminé… .. Il suffit d’ajouter quelques lignes à la fin de votre script de déploiement Shell ou batch.

0
incognito

J'ai résolu cette question avec ce paquet de pépites: https://github.com/Microsoft/slow-cheetah/blob/master/doc/transforming_files.md

C’est si facile d’installer et d’utiliser toutes les configurations dans la configuration de la solution active (dans mon cas, j’ai ajouté une nouvelle configuration "Test" pour le déploiement du test). 

Après cela, vous pouvez installer cette extension dans VS: https://marketplace.visualstudio.com/items?itemName=vscps.SlowCheetah-XMLTransforms .

Vous pouvez maintenant créer un nouveau sous-fichier de configuration pour les paramètres de configuration de l'application .xml ou .json dans VS à l'aide de cet outil (comme dans le manuel). Par exemple, j'ai des fichiers Debug, Test, Release (appsettings.Debug.json, etc.)

Étape suivante: configuration des profils de publication pour chaque configuration. Après la publication, vous n’avez qu’un seul fichier avec toutes les transformations nécessaires.

Les transformations fonctionnent comme une transormation classique .json envinronment dans les applications Web principales .net.

0
Aleksei Popovich

Honnêtement, je pense que ce n'est pas la bonne tâche pour un pipeline de construction. De plus, les fonctionnalités de publication de la dotnet cli sont très limitées. Allez à des outils externes comme Tseng vous a montré. Le déploiement est un autre domaine avec son propre ensemble de complexité que la construction.

Il n'y a pas de construction en place sur dotnet cli au-delà d'utiliser des outils externes!

0
Thomas

Vous pouvez utiliser les conditions MSBuild pour éventuellement inclure des fichiers dans la sortie de compilation (ou dans la sortie publiée).

<ItemGroup Condition="'$(Configuration)'=='Release'">
  <Content Remove="appsettings.Development.json;appsettings.Staging.json" />
  <None Include="appsettings.Development.json;appsettings.Staging.json" />
</ItemGroup>

Ce qui précède ignore les variantes du fichier appsettings.json de développement et de stockage intermédiaire lorsque la configuration cible de la compilation est Version.

0
Gabe Szabo