search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.38k stars 10k forks source link

Support configuring the local development environment name #51883

Open danroth27 opened 11 months ago

danroth27 commented 11 months ago

There are a number of places in ASP.NET Core now where we assume that local development happens in the "Development" environment. Users that choose to use a local development environment name other than "Development" then run into problems. For example, this user's Blazor WebAssembly debugging experience was broken until they finally realized it was because of they used "Local" for their local development environment name: https://twitter.com/hal00/status/1720507264090477031.

We could tell users to stick to the convention. But maybe we should provide a centralized way to specify the name used for local development so that users can change it in a consistent way if they want to.

javiercn commented 11 months ago

Just for reference,

this is already supported. The challenge becomes that when people use different defaults, they need to then manually register the set of default services that we register during development.

For example, the proxy is registered behind "env.IsDevelopment()". We can choose to make "env.IsDevelopment()" more extensive so that it can be configured with a different flag on launchSettings.json or become a config key like "detailedErrors" that we all recognice.

But IMO, unless you are doing something very specific there is no great value on changing the environment name for local dev for something else. I think it makes more sense when you have other things like "Production", "Staging", "Testing", etc., but that's it.

This has been a problem for a while, but I think if we do anything, we should decouple the signal that we use to turn dev features on, from the environment name.

ghost commented 11 months ago

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.

veertien commented 11 months ago

this is already supported

@javiercn, how is it supported?

ChrisDoernen commented 2 months ago

+1 for this issue.

Our use case is running playwright integration tests for a hosted WASM app. We'd like to call the environment "CI" but essentially are restricted to "Development" which causes a naming conflict.