FreeAndNil opened a new pull request, #311: URL: https://github.com/apache/logging-log4net/pull/311
Fixes #162 In a process that hosts the runtime natively there is no entry assembly for the configuration system to derive the config file path from, so reading an application setting fails in ClientConfigPaths with a PlatformNotSupportedException wrapped in a ConfigurationErrorsException. That matched none of the shapes IsMissingConfigurationSystem recognised, so log4net blamed the user's config file and repeated the report for every setting the static constructors read: seven log4net:ERROR blocks with a stack trace each, at startup, in a well configured application. A PlatformNotSupportedException anywhere in the inner exception chain is now treated as an absent configuration system, the same as the Native AOT case. A malformed config file cannot produce one, so unlike the FileNotFoundException and TypeLoadException cases it needs no check on which assembly it came from. The failure is logged once at debug level and application settings come from environment variables. Verified on Windows in a C++ host of the CoreCLR built for the purpose, in a host that loads the runtime through hostfxr, and in powershell.exe loading a netstandard2.0 build output: seven error blocks before, none after, and exactly one debug line with log4net.Internal.Debug on. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
