Exception calling GetLogger when compiled using PublishAOT

[vpenades]

We have a Windows project that we've set to use PublishAOT

When calling:

LogManager.GetLogger(typeof(SomeType));

We get this exception:

   System.PlatformNotSupportedException: Operation is not supported on this platform.
   at System.Reflection.Assembly.GetCallingAssembly() + 0x4a
   at log4net.LogManager.GetLogger(Type) + 0xe

As it happens, GetLogger calls Assembly.GetCallingAssembly(); which is not supported in AOT compiled binaries.

solutions:

I would add Net6.0 / Net8.0 target platforms, and use conditionals to use something other than GetCallingAssembly();

Also, I've seen #142 and #143 , unfortunately PublishAOT requires Trimming to be set and it cannot be opted out.

[gkna]

I am also facing same issue for the linux-x64 target platform
Unhandled Exception: System.PlatformNotSupportedException: Operation is not supported on this platform.
at System.Reflection.Assembly.GetCallingAssembly() + 0x4c
at log4net.LogManager.GetLogger(Type) + 0x11
at Program.

$(String[] args) + 0x41

Any help is appreciated.

[FreeAndNil]

@vpenades, @gkna I'm sorry, but I think we need to wait for dotnet/csharplang#4984 / dotnet/csharplang#9017
This will deliver an AOT-compatible equivalent (CallerIdentityAttribute) for Assembly.GetCallingAssembly().

[FreeAndNil]

There is now an open pull request for this: #306, on branch
Feature/306-aot-calling-assembly.
It is not merged yet and is not in any release, so please treat this as a status update and a
request for review rather than a release announcement.

If you can build that branch and try it against your project, that feedback would be very welcome
before it goes in — yours is the scenario it was written for:

git clone --branch Feature/306-aot-calling-assembly https://github.com/apache/logging-log4net.git
dotnet build logging-log4net/src/log4net/log4net.csproj -c Release

which leaves the assembly in build/Release/netstandard2.0/log4net.dll.

With that PR applied, log4net runs from a PublishAot build, with one condition: configuration
has to be done in code. Actual output from an AOT-published binary built from the branch:

INFO SomeType [1] 21:48:31 - hello from native aot
WARN SomeType [1] 21:48:31 - and a warning
ERROR SomeType [1] 21:48:31 - with an exception
System.InvalidOperationException: boom

FileAppender was verified separately and writes its file correctly.

Reproduction

Reproduced on .NET 10, PublishAot=true, linux-x64, against log4net built from master:

API	JIT	Native AOT
Assembly.GetCallingAssembly()	ok	throws PlatformNotSupportedException
Assembly.GetExecutingAssembly()	ok	ok
Assembly.GetEntryAssembly()	ok	ok
typeof(X).Assembly	ok	ok
new StackTrace().GetFrame(1).GetMethod()	ok	returns null

So there is no stack-walking fallback available under AOT; the calling assembly is simply not
recoverable at runtime.

Assembly.GetCallingAssembly() is called from 18 call sites in src/log4net, not just
GetLogger:

• LogManager — 9 (Exists, GetCurrentLoggers, GetLogger(string), GetLogger(Type),
  ShutdownRepository, ResetConfiguration, GetRepository, CreateRepository(Type), Flush)
• XmlConfigurator — 6
• BasicConfigurator — 2
• SystemInfo.GetTypeFromString(string, bool, bool) — 1

Why new target frameworks alone would not have fixed it

Adding net6.0/net8.0 TFMs plus #if does not solve this. AOT-ness is a publish mode, not a
target framework — the same net8.0 assembly runs both JIT-compiled and AOT-compiled, and there is
no compile-time conditional that distinguishes the two. A newer TFM buys exactly one thing:
RuntimeFeature.IsDynamicCodeSupported (netstandard2.1+/net5+) as a tidier probe than a
try/catch. It was not needed, and log4net still targets net462/netstandard2.0.

What the PR changes

1. The calling assembly. A once-computed flag, with the GetCallingAssembly() call left
inline in each public method. It cannot be extracted into a helper: the calling assembly of such
a helper is log4net itself, not the assembly that called log4net. A lambda does not work either —
its closure class is compiled into log4net.

public static ILog GetLogger(string name)
  => GetLogger(CallerAssembly.IsSupported ? Assembly.GetCallingAssembly() : CallerAssembly.Fallback, name);

CallerAssembly.Fallback is Assembly.GetEntryAssembly() ?? typeof(CallerAssembly).Assembly.
No API change, no per-call overhead.

2. Application settings. A trimmed System.Configuration cannot initialize, so every
SystemInfo.GetAppSetting() lookup reported a caught failure. That is now told apart from a
configuration file that genuinely does not parse — Native AOT surfaces both as
ConfigurationErrorsException, so only the inner exception (a MissingMethodException on
ClientConfigurationHost) distinguishes them. A missing configuration system is treated as a
property of the runtime rather than a fault: logged at debug level, with environment variables
standing in for the config file, exactly as already happens on Android. A malformed config file is
still reported as an error, and behaviour on .NET Framework is unchanged.

3. Trimming. This was the larger half. The trimmer had removed the constructors of everything
log4net creates reflectively, so no repository, pattern converter or locking model could be
instantiated — MissingMethodException on Hierarchy, then on every pattern converter in turn.
That flow is now annotated with DynamicallyAccessedMembers, polyfilled in log4net because the
trimmer matches the attribute by name and neither target framework declares it.

One part of this is worth calling out for anyone hitting the same class of bug: annotating was not
enough on its own, because the built-in converters were held in a Dictionary<string, Type>, and
a Type placed in a collection loses its annotation. The registries now hold ConverterInfo,
whose Type property carries the annotation, and are built through a generic method whose new()
constraint states the same requirement structurally — so a converter without a public parameterless
constructor now fails to compile rather than failing only in a trimmed build.

Configuration must be done in code

XML configuration cannot work under Native AOT and never will: XmlConfigurator names appender,
layout and filter types as strings, and the trimmer has no way to know they are needed. Configure
programmatically instead:

ConsoleAppender appender = new()
{
  Layout = new PatternLayout("%level %logger - %message%newline"),
  Threshold = Level.All,
};
appender.ActivateOptions();
BasicConfigurator.Configure(appender);

Conversion patterns work as usual — the built-in converters are preserved for you.

If the goal is to change verbosity without rebuilding, log4net cannot read the file but your
application can, and levels can be set through the API at any time:

Hierarchy hierarchy = (Hierarchy)LogManager.GetRepository();
if (hierarchy.LevelMap[levelNameFromYourConfigFile] is Level level)
{
  hierarchy.Root.Level = level;
}

Per-logger levels work the same way via ((Logger)hierarchy.GetLogger(name)).Level. The PR adds a
Native AOT and trimming page to the manual covering all of this.

Known limitations (with the PR applied)

• XML configuration is unavailable, as described above.
• log4net's own appSettings keys (log4net.NullText, log4net.NotAvailableText, …) are read from
  environment variables instead of app.config.
• Methods that infer a repository from their caller fall back to the entry assembly. This is
  invisible to applications with a single default repository, but if you use per-assembly
  repositories ([assembly: log4net.Config.Repository("...")] on a library), that library's
  loggers land in the entry assembly's repository. Use the overloads that take the assembly
  explicitly — LogManager.GetLogger(typeof(MyType).Assembly, typeof(MyType)) — which are exact on
  every runtime.
• Publishing may report IL3000 for SystemInfo.AssemblyLocationInfo, because Assembly.Location
  is empty for a single-file application. It affects location information only.

On the interceptor idea

We looked at it seriously and concluded it is not needed for AOT, so the PR does not include
one. If you disagree, the PR is the place to say so.

The gap it would close is real but narrow. Assembly identities do survive Native AOT — a two-project
harness reports lib and app as distinct — so a non-entry assembly really does get attributed to
the entry assembly. But that is only observable with per-assembly repositories, and it already has a
zero-code workaround in the explicit-Assembly overloads above.

Against that, an interceptor needs a generator shipped as analyzers/dotnet/cs, a
build/log4net.props setting <InterceptorsNamespaces> so consumers do not have to, a .NET 9.0.2xx+
SDK on the consumer side, and it still does nothing for pre-built third-party libraries or for VB/F#.

If it is ever revisited, the honest argument is performance — it removes a reflection call from
every GetLogger call site on all runtimes, not just AOT — and that deserves its own issue.

Sources

dotnet/csharplang#9017 (reply in thread)
https://github.com/dotnet/roslyn/blob/main/docs/features/interceptors.md

[FreeAndNil]

@vpenades @gkna can you test weather #306 unblocks you?

[FreeAndNil]

@vpenades @gkna please take a look at https://github.com/apache/logging-log4net/blob/Feature/306-aot-calling-assembly/src/site/antora/modules/ROOT/pages/manual/native-aot.adoc

[vpenades]

Sadly, we had to remove log4net from our build since we could not delay moving to AOT.

Other alternatives didn't work either, so we had to roll our own bare bones solution.

[FreeAndNil]

@gkna can you test this?