You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
make log4net usable from a PublishAOT build (#306)
Native AOT broke two things in the startup path (fixes#233 partially).
Assembly.GetCallingAssembly() throws PlatformNotSupportedException there, so
every overload that resolves the repository from the caller failed -
LogManager.GetLogger(Type) among them. Guard the 18 call sites with
CallerAssembly.IsSupported, a flag probed once, and fall back to the entry
assembly when the runtime does not implement the call. The call itself has to
stay in the public method whose caller is wanted, so it cannot be moved into
the helper.
SystemInfo.GetAppSetting() then failed as well, because System.Configuration
is trimmed away. Its catch never saw that: resolving the missing assembly
fails on entry to the method, before the try region, so the exception escaped
the static constructor as a TypeInitializationException and killed the
process. Read the setting through a separate, never inlined method so the
failure is raised inside the try block, latch the result so a permanent
failure is reported once rather than per lookup, and fall back to environment
variables the way the Android branch already does. That fallback also makes
log4net.NullText and log4net.NotAvailableText settable under AOT, where they
previously could not be configured at all.
Note that the fallback applies on .NET Framework too: a malformed app.config
now reads settings from the environment instead of returning null.
This does not make log4net AOT-clean - repositories, appenders and layouts are
still instantiated via Activator.CreateInstance, so an AOT app still fails
with MissingMethodException on Hierarchy's constructor.
0 commit comments