viktorgobbi commented on issue #162: URL: https://github.com/apache/logging-log4net/issues/162#issuecomment-2269236131
@FreeAndNil Thanks for the quick reply! > Are you trying to use log4net netstandard2.0 on net48? 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. > I can't even create a console app on net48 which uses log4net netstandard2.0. The compiler always prefers the net461 version for the output directory. 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. > My proposal would be using log4net net461 for windows powershell and log4net netstandard2.0 for powershell core. 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 `System.Configuration.ConfigurationManager` package (>= 5.0.0) and it turns out it is related to the content of the *powerShell.exe.config* which contains a section that is no longer supported. 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: But I still think that this could be an issue in other scenarios that needs to be addressed in the log4net package since [`System.Reflection.Assembly.GetEntryAssembly()`](https://learn.microsoft.com/en-us/dotnet/api/system.reflection.assembly.getentryassembly?view=netstandard-2.0) can return `null` and `System.Configuration.ConfigurationManager` in version 4.5.0 will throw a `PlatformNotSupportedException` in that case as mentioned in https://github.com/dotnet/runtime/issues/25027 which will lead, in my opinion, to the same error messages I originally posted. I currently have no example project since the powerShell core console is a managed application but whenever a powershell core is hosted in a native process this should be reproducible similar to the windows powershell case. -- 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]
