Defer ConcreteProxyCreator's AssemblyBuilder construction so endpoints without interface messages can start under NativeAOT

[ANcpLua]

Describe the suggested improvement

Is your improvement related to a problem? Please describe.

EndpointCreator.Configure() unconditionally constructs MessageMapper, whose constructor immediately constructs ConcreteProxyCreator, whose constructor immediately calls AssemblyBuilder.DefineDynamicAssembly. Reflection.Emit is not available under NativeAOT, so this throws PlatformNotSupportedException during endpoint creation — before any message is mapped. Every endpoint therefore fails at startup under PublishAot=true, including endpoints that use only class messages and would never need an interface-message proxy. Because IMessageMapper is set internally via settings.Set<IMessageMapper>(...), there is no consumer-side way to substitute it.

Minimal repro (net10.0 console app, NServiceBus 10.2.5, LearningTransport, assembly scanning disabled, explicit AddHandler<T>() registration, SystemJsonSerializer with a source-generated JsonSerializerContext, class messages only):

dotnet publish -c Release /p:PublishAot=true
./NsbAotRepro

Unhandled exception. System.PlatformNotSupportedException: Dynamic code generation is not supported on this platform.
   at System.Reflection.Emit.ReflectionEmitThrower.ThrowPlatformNotSupportedException() + 0x30
   at NServiceBus.ConcreteProxyCreator..ctor() + 0x24
   at NServiceBus.MessageInterfaces.MessageMapper.Reflection.MessageMapper..ctor() + 0x15c
   at NServiceBus.EndpointCreator.Configure() + 0x228
   at NServiceBus.EndpointCreator.Create(EndpointConfiguration, IServiceCollection) + 0x214
   at NServiceBus.EndpointExternallyManaged.Create(EndpointConfiguration, IServiceCollection) + 0x18
   at NServiceBus.ServiceCollectionExtensions.AddNServiceBusEndpoint(IServiceCollection, EndpointConfiguration, Object) + 0x1d4

The same app runs and round-trips messages under JIT, so the 10.2 scanning-free registration path works; endpoint creation is the only remaining AOT blocker in this scenario.

Describe the suggested solution

Defer the AssemblyBuilder construction in ConcreteProxyCreator to the first interface-message proxy request. Endpoints that never map an interface message would then start under NativeAOT; endpoints that do would fail at the first proxy request with a clear platform error instead of at startup.

Describe alternatives you've considered

Annotating the interface-message surface with [RequiresDynamicCode] and documenting the boundary, so AOT consumers get a build-time warning instead of a startup crash. Either direction would resolve this — happy to follow whichever you prefer, and to submit a PR for it if that is welcome.

Additional Context

Relevant code at 10.2.5:

• src/NServiceBus.Core/EndpointCreator.cs: var messageMapper = new MessageMapper(); settings.Set<IMessageMapper>(messageMapper);
• src/NServiceBus.Core/MessageInterfaces/MessageMapper/Reflection/MessageMapper.cs: public MessageMapper() => concreteProxyCreator = new ConcreteProxyCreator();
• src/NServiceBus.Core/MessageInterfaces/MessageMapper/Reflection/ConcreteProxyCreator.cs: constructor calls AssemblyBuilder.DefineDynamicAssembly(...).

The 10.2.0 announcement describes scanning-free registration as "a foundation for aligning with ahead-of-time compilation and trimming strategies in the future, even though full AOT and trimming compliance is not yet available" — this suggestion targets the next blocker on that path. It is related to but not a duplicate of #7748, which covers source-generated entry-point discovery for handler-less assemblies rather than the Reflection.Emit dependency in endpoint creation.

[danielmarbach]

Grüezi @ANcpLua

Are you currently blocked by this? We deliberately did not yet want to claim we are fully trimming compatible yet on this path but we are getting closer and closer. Did you run an experiment, or is your plan to roll out a trimmed endpoint? Can you give us a bit more background about your use cases and desires? It will tremendously help us to shape the future iterations toward that goal.

FYI We took a brief look at your suggestion and drafted a PR

[danielmarbach]

PR #7821 has been merged. Will be released in next minor.

[ANcpLua]

Grüezi @danielmarbach — thanks for the quick turnaround on #7821, and for the questions. I wanted to come back with data rather than opinions, so since the fix is merged but not yet released I packed current master (d072c26, MinVer-stamped 10.3.0-alpha.0.34) and ran it through the original repro plus a few extra probes. Answers first, results below.

Am I currently blocked? No. This comes out of a verification harness rather than a production rollout: I maintain Qyl.OpenTelemetry.AutoInstrumentation, a NativeAOT-first zero-code instrumentation runtime for .NET built on source generators (no IL weaving, no startup hooks). NServiceBus is one of its trace/metric lanes, and every lane is supposed to be verified end-to-end under PublishAot=true against the real library — which requires an NSB endpoint to actually start under AOT. Until #7821, the NServiceBus lane could only be executed under JIT and asserted for AOT.

Experiment or trimmed rollout? A standing experiment, effectively CI: the repro in this issue came straight out of that harness. My desire is exactly the direction you're heading — endpoint start plus concrete-message round-trip under AOT, with the structurally impossible parts (interface messages) failing clearly at the point of use, which is precisely what TrimmingSafeMessageMapper now does.

Validation of the merged fix — same scenario as the issue (net10.0, macOS arm64, LearningTransport, scanning disabled, AddHandler<T>(), SystemJsonSerializer with a source-generated context, class messages, externally managed hosting):

Run	NServiceBus	Outcome
JIT	10.3.0-alpha.0.34	✅ starts, class message round-trips — no behavior change
NativeAOT	10.2.7 (latest released)	❌ original crash, identical stack (ConcreteProxyCreator..ctor → PlatformNotSupportedException)
NativeAOT	10.3.0-alpha.0.34	✅ past endpoint creation — #7821 verified — then hits the next blocker (below)
NativeAOT + <TrimmerRootAssembly Include="NServiceBus.Core" />	10.3.0-alpha.0.34	✅ fully green: endpoint starts, class message round-trips, interface publish throws the designed point-of-use NotSupportedException, clean shutdown (13 MB arm64 binary)

So the fix does what it says, and with one coarse trimming workaround a scanning-free NServiceBus endpoint now runs end-to-end under NativeAOT.

The next blocker on the path (what the workaround papers over): type-registered pipeline behaviors lose their constructor metadata to the trimmer. PipelineSettings.Register<TBehavior>(string) doesn't annotate TBehavior with [DynamicallyAccessedMembers(PublicConstructors)], and RegisterStep.DefaultFactoryMethod activates via ActivatorUtilities.CreateInstance(provider, BehaviorType) — so the trimmer keeps the type (it's referenced via typeof) but strips the unreferenced parameterless constructor. First casualty is InferredMessageTypeEnricherBehavior:

System.InvalidOperationException: A suitable constructor for type
'NServiceBus.InferredMessageTypeEnricherBehavior' could not be located.

Two directions with the same shape as this issue: flow DynamicallyAccessedMemberTypes.PublicConstructors through the Register overloads and RegisterStep.BehaviorType, or register the built-in behaviors through the existing factory overload (Register(_ => new InferredMessageTypeEnricherBehavior(), …)), which is trivially trim-safe. Happy to file this as its own issue — and take a stab at a PR — if that's useful.

Two smaller observations from the green run:

• HostStartupDiagnosticsWriter uses reflection-based System.Text.Json, so AOT startup logs Failed to write startup diagnostics … Reflection-based serialization has been disabled (non-fatal). A source-generated context for the diagnostics payload — or skipping when !JsonSerializer.IsReflectionEnabledByDefault — would silence it.
• One data point reinforcing the concrete-messages guidance: interface messages were already incompatible with a source-generated JsonSerializerContext even under JIT — the runtime proxy (ISomethingHappened__impl) can't have compile-time serializer metadata, so STJ throws JsonTypeInfo metadata … was not provided by TypeInfoResolver. The advice in the new TrimmingSafeMessageMapper exception message is the right call on JIT too whenever source-gen STJ is in play.

Happy to re-run this harness against any RC or nightly you cut, and to contribute PRs on the remaining items if welcome. Looking forward to 10.3 — and thanks again for engaging so quickly on this.

[danielmarbach]

The next blocker on the path (what the workaround papers over):

I had a good smile on this "Claude" sentence. We are aware of most of those things and also have ideas on how to properly tackle this and the proxy part was "just one part".

That being said your message is a tremendously helpful data point for our next steps. We cannot make any promises when we will address those though. Please be patient with us and if you don't mind keep those things coming

For the host startup part feel free to send in a PR if you'd like and we can have a look at it. I was thinking there that instead of silencing we could have a better story in how we manage the diagnostic sections and their type information at least in the parts that we control in the framework but that might be more involved than "just silencing it" and those design iterations are usually more time consuming than we'd want to enforce to a community member sending in a contribution. My colleagues can handle it during my absence otherwise I'll get to it after the summer break

FYI I'm on a summer break soon and will be less responsive

[danielmarbach]

#7882 has been merged. Additonal follow through #7889 is still pending due to the larger surface area