Framework code should not depend on IsDevelopment

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: https://github.com/dotnet/aspnetcore/blob/d7187b01e87761c778a5c406802e8bfd9451f3cf/src/DefaultBuilder/src/WebHost.cs#L176-L183

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.

[msftbot[bot]]

Thanks for contacting us.

We’re moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it’s very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.