Application console .NET Core, comment configurer appSettings par environnement ?

Question

J'ai une application console .NET Core 1.0.0 et deux environnements. Je dois être en mesure d'utiliser appSettings.dev.json et appSettings.test.json en fonction des variables d'environnement que je définis au moment de l'exécution. Cela semble assez simple pour les applications web ASP.NET Core, grâce à l'injection de dépendances, à IHostingEnvironment et à la variable d'environnement EnvironmentName, mais comment dois-je organiser les choses pour l'application console (à part écrire mon propre code personnalisé qui utilise Microsoft.Framework.Configuration.EnvironmentVariables ) ?

Merci.

Answer 1

C'est ainsi que nous procédons dans notre .netcore l'application de la console. La clé ici est d'inclure le bon Dépendances sur votre projet à savoir ( peut-être pas tous, vérifiez en fonction de vos besoins ) et copie à la sortie l'appSetting.json en tant que partie de votre options de construction

  {
    "buildOptions": {
    "emitEntryPoint": true,
    "copyToOutput": {
       "include": [
       "appsettings*.json",
       "App*.config"
                 ]
          }
},

using Microsoft.Extensions.Configuration;
namespace MyApp
{
    public static void Main(string[] args)
    {
        var environmentName = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");

        var builder = new ConfigurationBuilder()
            .AddJsonFile($"appsettings.json", true, true)
            .AddJsonFile($"appsettings.{environmentName}.json", true, true)
            .AddEnvironmentVariables();
        var configuration = builder.Build();
        var myConnString= configuration.GetConnectionString("SQLConn");
    }
}

Answer 2

Pour ceux qui utilisent .NET Core version 2.1.0+ et Microsoft.Extensions.Hosting pour héberger leur application de console, vous pouvez utiliser le code suivant (selon l'article de Feiyu Zhou) réponse dans un autre fil) :

var hostBuilder = new HostBuilder()
    .ConfigureHostConfiguration(config =>
    {
        if (args != null)
        {
            // enviroment from command line
            // e.g.: dotnet run --environment "Staging"
            config.AddCommandLine(args);
        }
    })
    .ConfigureAppConfiguration((context, builder) =>
    {
        builder.SetBasePath(AppContext.BaseDirectory)
            .AddJsonFile("appsettings.json", optional: false)
            .AddJsonFile($"appsettings.{context.HostingEnvironment.EnvironmentName}.json", optional: true);
    })

Answer 3

Il y a deux IHostingEnvironment interfaces que vous devriez utiliser. L'une est destinée aux applications ASP.NET Core, l'autre aux applications .NET Core Console. Vous pouvez utiliser cet exemple de code pour les deux :

using System;
using System.IO;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.FileProviders;
using Microsoft.Extensions.Hosting.Internal;

namespace MyApplication.Common
{
    public static class ConfigurationFactory
    {
        /// <summary>
        /// Use for ASP.NET Core Web applications.
        /// </summary>
        /// <param name="config"></param>
        /// <param name="env"></param>
        /// <returns></returns>
        public static IConfigurationBuilder Configure(IConfigurationBuilder config, IHostingEnvironment env)
        {
            return Configure(config, env.EnvironmentName);
        }

        /// <summary>
        /// Use for .NET Core Console applications.
        /// </summary>
        /// <param name="config"></param>
        /// <param name="env"></param>
        /// <returns></returns>
        private static IConfigurationBuilder Configure(IConfigurationBuilder config, Microsoft.Extensions.Hosting.IHostingEnvironment env)
        {
            return Configure(config, env.EnvironmentName);
        }

        private static IConfigurationBuilder Configure(IConfigurationBuilder config, string environmentName)
        {
            return config
                .SetBasePath(Directory.GetCurrentDirectory())
                .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
                .AddJsonFile($"appsettings.{environmentName}.json", optional: true, reloadOnChange: true)
                .AddEnvironmentVariables();
        }

        /// <summary>
        /// Use for .NET Core Console applications.
        /// </summary>
        /// <returns></returns>
        public static IConfiguration CreateConfiguration()
        {
            var env = new HostingEnvironment
            {
                EnvironmentName = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") ?? "Production",
                ApplicationName = AppDomain.CurrentDomain.FriendlyName,
                ContentRootPath = AppDomain.CurrentDomain.BaseDirectory,
                ContentRootFileProvider = new PhysicalFileProvider(AppDomain.CurrentDomain.BaseDirectory)
            };

            var config = new ConfigurationBuilder();
            var configured = Configure(config, env);
            return configured.Build();
        }
    }
}

Answer 4

Si comme moi, vous essayez simplement d'avoir un fichier de configuration différent pour le mode Release et le mode Development, il suffit d'ajouter un fichier appsettings.Development.json avec le paramètre CopyToOutputDirectory défini à true dans la fenêtre de propriétés du fichier.

Maintenant, pour accéder au fichier en fonction de la configuration de la construction, vous pouvez utiliser le #if DEBUG directive du préprocesseur .

Voici un exemple :

static void Main(string[] args)
{

#if DEBUG
    var builder = new ConfigurationBuilder()
            .AddJsonFile($"appsettings.Development.json", true, true);
#else
    var builder = new ConfigurationBuilder()
            .AddJsonFile($"appsettings.json", true, true);
#endif

    var configuration = builder.Build();

    // ... use configuration
}

Answer 5

Ces mesures environnementales semblent convenir à la plupart des gens, mais je ne suis pas du tout d'accord avec toute cette gestion de l'environnement. Ni le runtime ni le système cible ne savent ce qu'il est. Seul vous, en tant que développeur ou mécanisme de déploiement, savez ce qu'est le système cible.

Tout le monde parle de la variable ASPNETCORE_ENVIRONMENT, même la documentation officielle comme ici https://docs.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-3.0 . Mais en fait, quelqu'un doit définir explicitement un système comme système de production, par exemple en définissant une fois manuellement ASPNETCORE_ENVIRONMENT. Voulez-vous vraiment supposer et vous fier au fait que ce paramètre est déjà défini dans chaque environnement que vous utilisez ? Non, vous ne pouvez pas. Que se passe-t-il si vous devez déployer une application console sur un serveur batch où aucun site Web n'est en cours d'exécution ? ASPNETCORE_ENVIRONMENT n'est pas disponible. Que faire si vous devez déployer et exécuter un webapi .net core sans IIS, uniquement avec Kestrel ? Pas de web.config et pas de variable d'environnement. Voulez-vous que votre équipe d'administration/opération définisse cette variable trompeuse pour votre application console ? Dans ce contexte, j'ai vu beaucoup de projets qui ont des paramètres d'application comme celui-ci par projet :

appsettings.json
appsettings.development.json
appsettings.test.json
appsettings.uat.json
appsettings.staging.json
appsettings.production.json

Gardez à l'esprit que par défaut, chacun de ces fichiers sera publié et également déployé sur le système cible. À première vue, il semble très facile de laisser l'environnement "décider" de la configuration à utiliser. Mais vous avez une configuration et aussi des informations d'identification potentiellement déployées sur un système qui n'est pas prévu pour cela.

Conclusion

Je recommande appsettings.json + appsettings.release.json. Le premier est seulement pour dev. Changez-le, jouez avec comme vous voulez. Le dernier est une configuration VALIDE prête pour le déploiement (processus). Avant que le déploiement ne commence, transformez la configuration pour qu'elle soit prête pour le système cible. C'est tout. Plus besoin de compter sur les paramètres de la machine cible, plus de configurations désordonnées. Gardez le contrôle total de votre application, même lorsque les serveurs changent rapidement (comme la mise à l'échelle en général, les VM, le cloud, etc.)

J'apprécie les commentaires constructifs :-)