Provide a way to override the global configuration file path

[JeremyKuhne]

Need to follow through how the default value gets set on .NET Framework and see if we can match. Notably, if there is a way to configure this via environment variables we should also allow doing this and update System.Configuration to pull from AppDomainSetup.ConfigurationFile.

At worst we should move the logic down from System.Configuration for generating this name.

Note that this value is settable. I believe that there is no way to get System.Configuration to reset after it does it's first load on the .NET Framework, but that should also be investigated.

[JeremyKuhne]

Note that I don't expect this to "fix" dotnet test. I've opened an issue on vstest to try and get the ability to set up config files when testing.

[danmoseley]

Came up with another major would-be porter.

[danmoseley]

@JeremyKuhne any new info on this one ? Wondering whether we must have it for 3.0.

[JeremyKuhne]

Wondering whether we must have it for 3.0.

Must? I don't think so, but this is painful for porting when using System.Configuration.

One fundamental problem is that we don't expose ConfigurationFile on AppDomainSetup anymore. On desktop that is how you found the current app.config. Test frameworks could customize the path when creating a new AppDomain to run tests on.

While we don't have multiple AppDomains any more we have one as our primary context. We could re-add ConfigurationFile and pull the value from the AppContext data store as we're doing for APP_CONTEXT_BASE_DIRECTORY. So adding:

public static partial class AppContext
{
    // Populated with "APP_CONTEXT_CONFIGURATION_FILE" much like "APP_CONTEXT_BASE_DIRECTORY"
    public static ConfigurationFile { get; }
}

public static partial class AppDomainSetup
{
    // This API exists on NetFX
    public static ConfigurationFile => AppContext.ConfigurationFile;
}

If this was set before System.Configuration grabs the value for the first time that would help some scenarios. That could be done via AppContext.SetData() or passed in through the cli's corehost (which would require additional work). Potentially this could alternatively be pushed via @vitek-karas startup hook?

Putting the hooks in our side would be relatively easy as you could follow the pattern used by APP_CONTEXT_BASE_DIRECTORY.

[vitek-karas]

I'm not sure what is the trigger to System.Configuration to grab the value for the first time, but I assume it's nothing in the CoreLib itself. In that case startup hook should be able to set the value in AppContext before this happens (via AppContext.SetData) since it runs before Main. So unless the startup hook itself somehow triggers System.Configuration it should work just fine.

CoreCLR's native host can already do this - in fact it will already work today via .runtimeconfig.json. It is possible to specify any property name/value pair which will be copied verbatim to the AppContext.GetData dictionary on runtime init. We're working on enabling custom native hosts to do the same programmatically through hosting APIs (but I guess that is not very interesting for the test scenarios).

[JeremyKuhne]

I'm not sure what is the trigger to System.Configuration to grab the value for the first time, but I assume it's nothing in the CoreLib itself.

It is just the static constructor. As we don't use it directly, user code should be able to hit it.

It is possible to specify any property name/value pair

What is the syntax for that?

[vitek-karas]

In the app's .runtimeconfig.json

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.0",
    "configProperties": {
        "APP_CONTEXT_CONFIGURATION_FILE": "myfile.config"
    },
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "3.0.0"
    }
  }
}

And then from managed code AppContext.GetData("APP_CONTEXT_CONFIGURATION_FILE").

[jkotas]

this is painful for porting when using System.Configuration.

Do we have a customer report about what people end up doing to make this work today? It would be useful to validate that this proposal will make it significantly better.

We do not have end-to-end support for the XML config files in the .NET Core tooling. Unless we fix that, the XML config file experience on .NET Core is always going somewhat worse compared to .NET Framework.

This is very similar to https://github.com/dotnet/corefx/issues/36433. Both are about components that just need piece of data, and this piece of data happened to live with AppDomainSetup in .NET Framework.

[JeremyKuhne]

Do we have a customer report about what people end up doing to make this work today?

They are having to rewrite their code or copy over the shared test app.config on the box.

Unless we fix that, the XML config file experience on .NET Core is always going somewhat worse compared to .NET Framework.

Yeah, I don't really expect to make this painless, there just isn't a way to do this now. Idea is MSTest can just push the app.config for the actual tested assembly using this mechanism- or as a hack users can poke it themselves if they get to it early enough.

I don't imagine there is a lot of code out there that needs to read the config path out of AppDomainSetup, but it wouldn't hurt to have it for any other cases that do.

[JeremyKuhne]

The planned workaround here is to read from `AppDomain.CurrentDomain.GetData("APP_CONTEXT_CONFIGURATION_FILE") and use that if it exists.

Here is where the change needs to be made:

https://github.com/dotnet/corefx/blob/a10890f4ffe0fadf090c922578ba0e606ebdd16c/src/System.Configuration.ConfigurationManager/src/System/Configuration/ClientConfigPaths.cs#L63

Overiding can be done via https://github.com/dotnet/corefx/issues/32095#issuecomment-483425717 or making sure you get in and set the value on AppDomain before ConfigurationManager is first used.

dotnet/corefx#36897 tracks creating an API to move this logic up to AppDomainSetup.

[bricelam]

cc @divega

This hook would help the EF6 tests. For now, we work around it with a bit of MSBuild magic:

<ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp3.0'">
  <None Update="App.config">
    <Link>xunit.console.dll.config</Link>
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </None>
</ItemGroup>

Note, xunit.console.dll is the entry assembly when running our tests.

[danmoseley]

Moving to Future as this is not required to ship 3.0.