-
Notifications
You must be signed in to change notification settings - Fork 330
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
PlatformNotSupportedExceptions when loading log4net #162
Comments
@viktorgobbi I can reproduce your problem. Are you trying to use log4net netstandard2.0 on net48? This will probably not work. My proposal would be using log4net net461 for windows powershell and log4net netstandard2.0 for powershell core. |
@FreeAndNil Thanks for the quick reply!
Yes, the idea was to provide one assembly targeting .netstandard2.0 for both windows powerShell and powerShell core to keep the deployment simple. Other than this issue it also worked quite well. It is probably worth mentioning that log4net seems to work correctly, the error messages are only logged directly to the console which is the main problem.
In our case we have an intermediate nuget package which targets .netstandard2.0 and depends on log4net and our assemblies containing the powershell cmdlets also target .netstandard2.0 which is why it has to use the .netstandard2.0 assembly of log4net.
I came to the same conclusion but I am trying to avoid that as it would complicate our build and deployment quite a lot and as long as it's only an internal log message it doesn't pose that big of an issue for us. I did some more research and found out why it wouldn't work with newer versions of the I also managed to get the .netstandard2.0 assembly working without errors on .net framework but only through reflection so not really a solution but more like a fragile workaround. FYI: |
@viktorgobbi Thanks for the detailed explanation and your reasoning. |
Hi,
we recently ran into a problem with log4net where
PlatformNotSupportedException
s are logged after switching from thenet45
build to thenetstandard2.0
assembly of log4net.We ran into this issue with class libraries ( to provide windows powerShell cmdlets) where we use log4net. We are currently in the process of migrating our projects to target .net standard2.0 but after the migration we noticed error messages when log4net is loaded in a windows powershell console (powershell.exe) process. The following is logged to the console:
This issue is not reproducible with the log4net assembly targeting
net45
.I have tried to analyze this issue and traced it down to the following points:
System.Reflection.Assembly.GetEntryAssembly()
returnsnull
(easily observable by starting a powershell.exe console and running[System.Reflection.Assembly]::GetEntryAssembly()
)System.Configuration.ConfigurationManager
in Version 4.5.0 which throws aPlatformNotSupportedException
when theAssembly.GetEntryAssembly()
call returnsnull
but this was addressed with Version >= 5.0.0 and was tracked in dotnet/runtime#25027logging-log4net/src/log4net/Core/LoggerManager.cs
Line 108 in ad0180f
logging-log4net/src/log4net/Util/SystemInfo.cs
Line 85 in ad0180f
logging-log4net/src/log4net/Util/LogLog.cs
Line 174 in ad0180f
call
log4net.Util.SystemInfo.GetAppSetting(string)
which for netstandard2.0 callsConfigurationManager.AppSettings[key]
which ultimately causes the exception that is logged.I've tried using a newer version of the
System.Configuration.ConfigurationManager
package but ran into similar issues but with other error messages and since we only provide class libraries and cannot modify the app.config for the powershell.exe we have no good way to influence the binding behavior to get log4net working with a newerSystem.Configuration.ConfigurationManager
version in a production environment. I did not figure out why the issue is not present in the log4net assembly that is targeting net45 but I assume it has to do with the implementation ofSystem.Configuration.ConfigurationManager
in .NET Framework versus the one provided by the Nuget package.We are using log4net 2.0.14 but the issue is also reproducible with the latest version (v2.0.17 as of writing this).
I've attached a very simple solution to reproduce the issue log4netConfigErrorSln.zip
To reproduce it:
Add-Type -Path "<pathToSolutionOutput>\netstandard2.0\Lib1.dll"
[Lib1.Lib1]::LogSomething()
in the powershell console to call the static method and force log4net to initializeAny suggestions or workarounds would be appreciated!
The text was updated successfully, but these errors were encountered: