Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WPF for .NET Core throws first chance exceptions due to .NET Core limitations #2395

Closed
AArnott opened this issue Jan 3, 2020 · 5 comments
Closed
Assignees
Milestone

Comments

@AArnott
Copy link

@AArnott AArnott commented Jan 3, 2020

  • .NET Core Version: 3.1
  • Windows version: 1909
  • Does the bug reproduce also in WPF for .NET Framework 4.8?: No

Problem description:

WPF for .NET Core throws a multiple first-chance exceptions during startup because AppSettings isn't available on .NET Core.

Actual behavior:

System.Configuration.ConfigurationErrorsException
  HResult=0x80131902
  Message=Configuration system failed to initialize
  Source=System.Configuration.ConfigurationManager
  StackTrace:
   at System.Configuration.ConfigurationManager.PrepareConfigSystem() in /_/src/System.Configuration.ConfigurationManager/src/System/Configuration/ConfigurationManager.cs:line 150

  This exception was originally thrown at this call stack:
    System.Configuration.ClientConfigPaths.ClientConfigPaths(string, bool) in ClientConfigPaths.cs
    System.Configuration.ClientConfigPaths.GetPaths(string, bool) in ClientConfigPaths.cs
    System.Configuration.ClientConfigurationHost.ConfigPaths.get() in ClientConfigurationHost.cs
    System.Configuration.ClientConfigurationHost.GetStreamName(string) in ClientConfigurationHost.cs
    System.Configuration.ClientConfigurationHost.IsAppConfigHttp.get() in ClientConfigurationHost.cs
    System.Configuration.Internal.DelegatingConfigHost.IsAppConfigHttp.get() in DelegatingConfigHost.cs
    System.Configuration.ClientConfigurationSystem.ClientConfigurationSystem() in ClientConfigurationSystem.cs
    System.Configuration.ConfigurationManager.EnsureConfigurationSystem() in ConfigurationManager.cs

Inner Exception 1:
PlatformNotSupportedException: Operation is not supported on this platform.

Expected behavior:

I expect WPF for .NET Core avoids calling APIs that are known to not work on .NET Core so that these first chance exceptions aren't thrown.

@AArnott

This comment has been minimized.

Copy link
Author

@AArnott AArnott commented Jan 3, 2020

This also appears in FrameworkCompatibilityPreferences:

@ericstj

This comment has been minimized.

Copy link
Member

@ericstj ericstj commented Jan 6, 2020

/cc @JeremyKuhne @maryamariyan

AppSettings should be usable on .NETCore (see https://gist.github.com/ericstj/20497889f9d71ceb5d0f5fcc84cdede1), though we wouldn't recommend building new things around it. @AArnott it looks like you're hitting this:
https://github.com/dotnet/runtime/blob/4f9ae42d861fcb4be2fcd5d3d55d5f227d30e723/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ClientConfigPaths.cs#L49-L56

Perhaps you're hitting this because the way you're hosting CoreCLR doesn't set EntryAssembly? That might be something to try to root cause here: I suspect other things might fallout of this.

@AArnott

This comment has been minimized.

Copy link
Author

@AArnott AArnott commented Jan 6, 2020

Oh, quite possibly. I'll see if I can figure out how to set that EntryAssembly property. So far the only property I'm setting is APP_CONTEXT_BASE_DIRECTORY, and I'm discovering properties I need to set as I go. Is there a complete list of properties that may need setting in a custom .NET Core host?

@ericstj

This comment has been minimized.

Copy link
Member

@ericstj ericstj commented Jan 6, 2020

Looks to be the issue discussed here: dotnet/corefx#27091. I couldn't find any hook to set EntryAssembly. As @jkotas mentioned it's only set on the appdomain when ExecuteMainMethod is called.

@rladuca

This comment has been minimized.

Copy link
Member

@rladuca rladuca commented Jan 8, 2020

Thanks @ericstj for checking into it.

@AArnott WPF isn't going to change that code in any significant fashion unless there is an overriding need to. There are significant switches that help ensure backward compatibility with .NET Framework and minimize problems with porting to .NET Core that we want to preserve. All of these are based around ConfigurationManager.

I'm going to close this as there doesn't seem like any actions for WPF here.

@rladuca rladuca closed this Jan 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.