简体   繁体   中英

Use custom names for IHostingEnvironment

We are running ASP.NET Core and using IHostingEnvironment eagerly.

Because of conventions in our organization, our environment names don't match those of the default IHostingEnvironment implementation.

To work around this we have made the following extension methods:

public static class HostingEnvironmentExtensions
{
        public static bool IsProd(this IHostingEnvironment env) => env.IsEnvironment("prod");            

        public static bool IsTest(this IHostingEnvironment env) => env.IsEnvironment("test");                 
}

This works fine, but feels kind of dangerous because the default methods of IsProduction and IsStaging now don't work the way you'd expect.

What is the proper way to deal with environment names being different from the ASP.NET Core defaults?

You could solve this by creating your own implementation. I created my own IWorkingEnvironment interface like this:

public interface IWorkingEnvironment
{
    string EnvironmentName { get; set; }
}

And my own 'known' environment names:

public static class EnvironmentNames
{
    public static readonly string Local = nameof(Local);

    public static readonly string Dev = nameof(Dev);

    public static readonly string Test = nameof(Test);

    public static readonly string Prod = nameof(Prod);
}

Followed by the extension methods on IWorkingEnvironment :

public static class WorkingEnvironmentExtensions
{
    public static bool IsLocal(this IWorkingEnvironment environment)
    {    
        return environment.EnvironmentName == EnvironmentNames.Local;
    }

    public static bool IsDev(this IWorkingEnvironment environment)
    {    
        return environment.EnvironmentName == EnvironmentNames.Dev;
    }

    // etc...
}

Then my implementation of IWorkingEnvironment using the ASP.NET IHostingEnvironment :

public class AspNetWorkingEnvironment : IWorkingEnvironment
{
    private readonly IHostingEnvironment _hostingEnvironment;

    public AspNetWorkingEnvironment(IHostingEnvironment hostingEnvironment)
    {
        _hostingEnvironment = hostingEnvironment;
    }

    public string EnvironmentName => _hostingEnvironment.EnvironmentName;
}

Now all we have to do is register the AspNetWorkingEnvironment as implementation of IWorkingEnvironment (using a singleton lifetime) in our dependency injection container:

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<IWorkingEnvironment, AspNetWorkingEnvironment>();

    // etc...
}

The cleanest way would be to extend your own type that implements IHostingEnvironment and inject it into your controllers and services.

But, if you insist on relying on the built-in methods, you can (somewhat dangerously) override the string values in the EnvironmentName type to match your custom values:

public Startup(IHostingEnvironment env)
{
    var envNameType = typeof(EnvironmentName);

    envNameType.GetField(EnvironmentName.Development).SetValue(null, "dev");
    envNameType.GetField(EnvironmentName.Production).SetValue(null, "prod");
    envNameType.GetField(EnvironmentName.Staging).SetValue(null, "stag");

    // given that current environment name == "prod", both would evaluates to 'true'
    var isInProd = env.IsEnvironment("prod");
    var isProd = env.IsProduction();

    // ...
}

Internally, the built-in IsEnvironment() method is relying on the values from that EnvironmentName to determine the environment name.

See Source

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM