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.