Environment variables still affect DebugProxy

[SteveSandersonMS]

I was getting some errors when trying to launch the debugger on my machine - Kestrel couldn't start because it said something was already listening on the same port. It appears to be because the debug proxy is still trying to inherit environment variables from the parent process.

By putting a breakpoint on the following line in DebugProxyHost.cs, it's possible to confirm that the EnvironmentVariablesConfigurationProvider is still being used:

It looks like this is because both GenericWebHostBuilder and WebHostBuilder (not certain which is used in this case) are hardcoded to call .AddEnvironmentVariables(prefix: "ASPNETCORE_") in their constructors.

As such I'm not sure what is the recommended pattern for not loading config from environment variables. @Tratcher - do you have any suggestions?

I investigated to see if we could remove the EnvironmentVariablesConfigurationProvider after the builder is created, but that's not easy since by the time ConfigureAppConfiguration gets called, that provider is already nested several levels deep in ChainedConfigurationSource instances, which seems to be immutable.

If nothing else works we could go back to our previous pattern of removing all environment variables that start with the ASPNETCORE_ prefix before launching the debug proxy, but cc @captainsafia for any other ideas.

[Tratcher]

I see what you mean.

aspnetcore/src/Hosting/Hosting/src/GenericHost/GenericWebHostBuilder.cs

Lines 34 to 40 in f990751

	_config = new ConfigurationBuilder()
	.AddEnvironmentVariables(prefix: "ASPNETCORE_")
	.Build();
	_builder.ConfigureHostConfiguration(config =>
	{
	config.AddConfiguration(_config);

Could you remove that provider in ConfigureHostConfiguration?

[Tratcher]

Also, I suggest switching from ConfigureWebHostDefaults to ConfigureWebHost. It won't completely remove this issue, but it will give you the lowest level of control.

[SteveSandersonMS]

Could you remove that provider in ConfigureHostConfiguration?

I tried, but it didn't seem feasible because by the time ConfigureHostConfiguration runs, that provider is already nested several levels deep in ChainedConfigurationSource instances. These instances don't have any API to tell you about their underlying sources, and even if they did, they don't expose any APIs for mutating those sets.

Also it's not feasible for ConfigureHostConfiguration to completely empty the set of configuration sources, because then we'd lose the in-memory config established inside ConfigureWebHostDefaults (or ConfigureWebHost).

[SteveSandersonMS]

Update: @Tratcher and I discussed this on a call and after some debugging, came to the conclusion that since we want to eliminate all inheritance of ASP.NET-related env vars from parent to child, it's not desirable to work around this using ConfigureWebHost (not that we could make this work anyway, since IISExpress injects itself into the child via the same inheritance of env vars).

Suggested plan:

• For Blazor 3.2.0, we go back to removing the ASPNETCORE_* env vars. Are you OK to look into doing this, @captainsafia?
• For ASP.NET Core 5.0, @Tratcher will file an issue suggesting we provide a way of not having an EnvironmentVariablesConfigurationProvider in the web host

[captainsafia]

For Blazor 3.2.0, we go back to removing the ASPNETCORE_* env vars. Are you OK to look into doing this, @captainsafia?

Yes, I'll prep a PR for this.

[Tratcher]

Filed #20328 for 5.0

[captainsafia]

Thanks, @Tratcher!

Closing this as it has been resolved in #20326.