… time
Add a bool Eager property to [Singleton<TImplementation>] and [Singleton<TImplementation, TService>] so a singleton can be constructed at container build time instead of lazily on first resolve. When set, the generated container root's constructor resolves each eager singleton in registration order, after the root's fields are initialized - the synchronous analog of InitializeAsync, which warms only the async-initialized singletons. Because each eager construction routes through the singleton's own cached static resolver (called with the root), a disposable eager singleton is tracked and disposed with the container exactly like a lazily-resolved one. Eager is exposed on the Singleton attribute only (the open-generic Type-ctor form carries no options), so a stray flag on a coalesced non-singleton is ignored.
Eager is for synchronous construction, so an eager singleton that is async-initialized (or reaches one through its non-deferred dependencies) cannot be built synchronously in the strict default and is the new error AWT161 - InitializeAsync warms it instead, or [Container(SyncResolveAfterInit = true)] emits a blocking synchronous resolver that allows synchronous eager construction while async initialization still runs in InitializeAsync. Missing-dependency, cycle and captive cases through an eager singleton are already covered by AWT101/102/105.
AWK->AWT mapping: the prototype's AWK124 maps to AWT161. The prototype's AWK125 (an eager singleton coexisting with a user-declared container constructor) is not ported: on current main the container is a static class and the eager-activation constructor is emitted on the generated Root, which always has a generated constructor a user can neither replace nor conflict with, so the condition cannot arise.
Adds behavior tests (eager constructed before any resolve and cached, lazy not; registration order; disposable disposed with the container), generator tests (the eager calls in the root constructor, registration order, no call for a lazy singleton, AWT161 in strict mode, allowed in pragmatic mode), and updates the public-API approval files for the new Eager property.
Add a bool
Eagerproperty to[Singleton<TImplementation>]and[Singleton<TImplementation, TService>]so a singleton can be constructed at container build time instead of lazily on first resolve. When set, the generated container root's constructor resolves each eager singleton in registration order, after the root's fields are initialized - the synchronous analog ofInitializeAsync, which warms only the async-initialized singletons. Because each eager construction routes through the singleton's own cached static resolver (called with the root), a disposable eager singleton is tracked and disposed with the container exactly like a lazily-resolved one. Eager is exposed on the Singleton attribute only (the open-generic Type-ctor form carries no options), so a stray flag on a coalesced non-singleton is ignored.Eager is for synchronous construction, so an eager singleton that is async-initialized (or reaches one through its non-deferred dependencies) cannot be built synchronously in the strict default and is the new error AWT161 -
InitializeAsyncwarms it instead, or[Container(SyncResolveAfterInit = true)]emits a blocking synchronous resolver that allows synchronous eager construction while async initialization still runs inInitializeAsync. Missing-dependency, cycle and captive cases through an eager singleton are already covered by AWT101/102/105.Adds behavior tests (eager constructed before any resolve and cached, lazy not; registration order; disposable disposed with the container), generator tests (the eager calls in the root constructor, registration order, no call for a lazy singleton, AWT161 in strict mode, allowed in pragmatic mode), and updates the public-API approval files for the new Eager property.