Repository navigation
Fix unkeyed DependsOn ServiceKey resolution (#112) - #119
Conversation
Co-authored-by: Codex <codex@openai.com>
Co-authored-by: Codex <codex@openai.com>
…ies (#112) Co-authored-by: Codex <codex@openai.com>
|
Implemented in draft PR #119: #119 The defect came from treating [ServiceKey] as contextual injection when the effective key was null. Constructor selection could reject a registered int parameter, while argument resolution silently supplied null for string/object parameters. Both paths now require a non-null effective key before injecting it. Without one, the existing ordinary-registration/default path applies, matching native Microsoft DI. For example, a registered int value 42 is now supplied to an unkeyed mapped constructor even when its key parameter has [ServiceKey]. Named value/key overrides still run first; genuine non-null keys retain type validation. Registered null factory results do not become optional defaults, missing required registrations fail before unrelated activation, and factory exceptions pass through unchanged. The fix adds no reflection and updates the README and vNext changelog. Tests were committed first. The 240 new cases per target produced 138 failures and 102 passing controls before the fix on all four targets. Four older cases asserted the defect's null-injection behavior; corrected native expectations also failed before the fix, with their two keyed controls passing. Verification for final commit
Paused for review. This is the last bug in the original #106–#112 list; after review and merge, a release-validation checkpoint is appropriate. No release actions were taken. |
Unkeyed or explicit-null-key
DependsOnregistrations treated[ServiceKey]as contextual injection even without an effective key. This injected null into reference-type parameters and rejected registered value-type parameters. Native Microsoft DI resolves those parameters from ordinary registrations or optional defaults.Fixes #112.
Constructor selection and argument resolution now inject
[ServiceKey]only when the effective key is non-null. Named value/key overrides remain first; non-null keys retain their existing type checks. Ordinary registered null results, missing required dependencies, optional defaults and factory exceptions keep their established behavior. This uses the existing resolution path and adds no reflection. The README and vNext changelog describe the corrected contract.Regression tests were committed before the implementation. The 240 new cases per target compare native DI with mapped activation through plain
BuildServiceProvider(), Mammoth's snapshot provider and its diagnostic provider, covering string/object/int/nullable-int parameters, unkeyed/null-key contexts, registrations/defaults/null results/exceptions, lifetimes, named overrides and genuine non-null keys. Before the fix, 138 failed and 102 passed on every target. Four older fixture cases assumed the faulty null-injection behavior; their corrected native expectations also failed before the fix (with two keyed controls passing).Verification on Windows:
ContinuousIntegrationBuild=True: passed; zero errors, zero compiler/analyzer warnings. Two existing package-support warnings state that Microsoft.Extensions.Telemetry.Abstractions 10.0.0 and Microsoft.Extensions.Diagnostics.Testing 10.0.0 do not claim net472 support.Exact final-commit CI evidence will be added in a PR discussion comment after GitHub Actions completes. Draft for review; no merge, release or publication actions requested.
Co-authored-by: Codex codex@openai.com