Framework code should not depend on IsDevelopment

[Xerillio]

Is your feature request related to a problem? Please describe.

I found that I had to manually check for the appropriate environment name(s) to enable user secrets in my application. ASP.NET Core only enables user secrets if the currently running environment is named "Development" and therefore require custom implementation to enable if your team does not use the same naming conventions as has been predefined by ASP.NET Core.

The code snippet in question:

aspnetcore/src/DefaultBuilder/src/WebHost.cs

Lines 176 to 183 in d7187b0

	if (env.IsDevelopment())
	{
	var appAssembly = Assembly.Load(new AssemblyName(env.ApplicationName));
	if (appAssembly != null)
	{
	config.AddUserSecrets(appAssembly, optional: true);
	}
	}

IsDevelopment and its sibling extension methods are used internally in ASP.NET Core to enable/disable certain features when running the application in different environments. I suspect some 3rd party libraries do so likewise (although I have no experience with such). This helps a developer setting up their local environment for better debugging capabilities etc., while avoiding enabling those same features in production environments as they may be unsafe/unfit for a production application.

Personally, I would consider a development environment to not only be the developers local machine but could just as well be a server-hosted application shared by multiple developers where the application is deployed prior to a "test" environment. As such two environments may (and very likely will) use a different configuration setup while still enabling certain debugging features, having only one name for what constitutes a "development" environment limits or completely disables the help provided by ASP.NET Core out of the box.

Describe the solution you'd like

To combat the issue described above I would suggest allowing the developer to define when IsDevelopment etc. should return true. This could be done e.g. through a configuration variable similar to ASPNETCORE_ENVIRONMENT (say ASPNETCORE_DEVELOPMENT_ENVIRONMENTS) that takes a comma-separated list of names considered to be a "development" environment. Alternatively, instead of implementing IsDevelopment etc. as extension methods they could be implemented such that they're overridable.

Additional context

I noticed #26539 has already brought this up but was closed. However, I believe the feature request deserves a bit more consideration with some additional context. Hopefully I provided that.

[Tratcher]

We've avoided using IsDevelopment in most framework code exactly because of issues like this. IsDevelopment is primarily used in app/template code so you can customize the environment logic.

Rather than trying to fix IsDevelopment, we should fix these sites where it's used to be based on more targeted external input and have the IsDevelopment check moved back to app code like Program.CreateHostBuilder.

[BrennanConroy]

We need to change this in Runtime too for generic host.

And look at other spots that we use this pattern.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[shirhatti]

There are currently a few places where we use IsDevelopment() in framework code, where isn't an alternative configuration (via options) to customize the behavior.

We need to address all these cases:

• UserSecrets
• StaticWebAssets
• SPA services?
• UserSecrets in Generic host