Remove IHostingEnvironment.Configuration property

[lodejard]

The fact that the hosting engine uses iconfiguration to grab some options at startup is its own business. It doesn't even need to be closed over after the builder/application start has completed.

There's nothing an application would correctly do while poking around or grabbing settings from the hosting engine's configuration sources.

[Tratcher]

#488
Command line args was one example.

[davidfowl]

It's a really nice way to flow arbitrary config from the hosting API to the app

[lodejard]

Nope. It's a really bad way to make people think it's a good idea to use Hosting.json and hostingEnvironment.Configuration as the new "System.Configuration" singleton. Hosting.json is only to configure hosting, it's not the aspnet5 version of appSettings.

@Tratcher command line args are better handled with .AddCommandLine(Environment.GetCommandLineArgs()) because the application will almost certainly have a different set of cli-friendly switch aliases for their configuration settings.

This property absolutely must be removed. It's an actively incorrect thing to use.

[Tratcher]

Environment.GetCommandLineArgs() isn't available on CoreCLR, correct?

[lodejard]

Seemed to be, in the dnxcore tfm at least, which I think is the same as coreclr for that Type

Sent from mobile device

---

From: Chris Rmailto:notifications@github.com
Sent: ‎12/‎17/‎2015 1:44 PM
To: aspnet/Hostingmailto:Hosting@noreply.github.com
Cc: Louis DeJardinmailto:lodejard@microsoft.com
Subject: Re: [Hosting] Remove IHostingEnvironment.Configuration property (#528)

Environment.GetCommandLineArgs() isn't available on CoreCLR, correct?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/528#issuecomment-165589117.

[davidfowl]

Nope. It's a really bad way to make people think it's a good idea to use Hosting.json and hostingEnvironment.Configuration as the new "System.Configuration" singleton. Hosting.json is only to configure hosting, it's not the aspnet5 version of appSettings.

I disagree. If you look at WebApplicationBuilder without hosting.json, it's an API that can be used to set arbitrary settings that need to flow to the application.

var config = new ConfigurationBuilder()
                         .AddJsonFile("something.json")
                         .AddEnvironmentVariables()
                         .Build();

var application = new WebApplicationBuilder()
                       .UseConfiguration(config)
                       ...
                       .Build();

@Tratcher command line args are better handled with .AddCommandLine(Environment.GetCommandLineArgs()) because the application will almost certainly have a different set of cli-friendly switch aliases for their configuration settings.

That doesn't even work because the first arg is the application name, so it's really .AddCommandLine(Environment.GetCommandLineArgs().Skip(1).ToArray())

This property absolutely must be removed. It's an actively incorrect thing to use.

I don't see why.

/cc @DamianEdwards

[lodejard]

I totally get the motivation, but there are a dozen ways to pass references from-code-to-code that don't involve an IConfiguration on IHostingEnvironment.

It's confusing to have templates which show a configuration loaded in startup constructor, and have a configuration passed on hosting environment which is ignored.

Unless the template has also been changed to move the configuration loading outside of the startup class? In which case hosting shouldn't be connected to a hosting.json be default.

The connection-by-default was only necessary for the case when no user code ran before startup was loaded.

[lodejard]

Lets talk when you're back in the states :)

[davidfowl]

Sure but API freeze is coming up soon. So we should remove it and have examples on how to do it if we're going to do it

[muratg]

Moving this to Backlog as we will be in RC2 ask mode very soon. If you feel strongly about this issue, please ping me.