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
{{ message }}
Repository navigation
DependencyInjection generic constraint validation incorrectly rejects struct constraint on mobile #127564
Microsoft.Extensions.DependencyInjection.Tests is failing on mobile platforms (iOS, tvOS, macCatalyst, Android) with errors related to generic constraint validation. The DI container's ValidateTrimmingAnnotations method is incorrectly rejecting implementations that have a new() constraint when the service interface doesn't have one.
The error states:
Generic implementation type 'ClassWithStructConstraint1' has a DefaultConstructorConstraint ('new()' constraint), but the generic service type 'IFakeOpenGenericService1' doesn't.
This validation is overly restrictive. An implementation can have more constraints than the interface it implements — that's valid and safe. The constraint on the implementation guarantees that any type argument passed will satisfy the implementation's needs, which includes satisfying the less-restrictive interface. The validation logic appears to be requiring exact constraint matching instead of allowing implementation constraints to be a superset of interface constraints.
This is a product bug in the DI container's constraint validation logic, not a test issue. The same tests pass on desktop platforms.
Impact on platforms
Failing on all tested mobile platforms in build 1399212 (2026-04-28):
From maccatalyst-arm64 Helix work item Microsoft.Extensions.DependencyInjection.Tests (console log):
1) [FAIL] Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactoryTest.CreateCallSite_ReturnsService_IfClosedTypeSatisfiesStructGenericConstraint
Assembly: [Microsoft.Extensions.DependencyInjection.Tests, Version=11.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60]
Exception messages: System.ArgumentException : Generic implementation type 'Microsoft.Extensions.DependencyInjection.Specification.Fakes.ClassWithStructConstraint`1' has a DefaultConstructorConstraint ('new()' constraint), but the generic service type 'Microsoft.Extensions.DependencyInjection.Specification.Fakes.IFakeOpenGenericService`1' doesn't.
Exception stack traces: at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.ValidateTrimmingAnnotations(Type serviceType, Type[] serviceTypeGenericArguments, Type implementationType, Type[] implementationTypeGenericArguments)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.Populate()
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactoryTest.GetCallSiteFactory(ServiceDescriptor[] descriptors)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactoryTest.CreateCallSite_ReturnsService_IfClosedTypeSatisfiesStructGenericConstraint()
at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
2) [FAIL] Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactoryTest.CreateCallSite_Throws_IfClosedTypeDoesNotSatisfyStructGenericConstraint
Exception messages: System.ArgumentException : Generic implementation type 'Microsoft.Extensions.DependencyInjection.Specification.Fakes.ClassWithNewConstraint`1' has a DefaultConstructorConstraint ('new()' constraint), but the generic service type 'Microsoft.Extensions.DependencyInjection.Specification.Fakes.IFakeOpenGenericService`1' doesn't.
3) [FAIL] Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactoryTest.CreateCallSite_Throws_IfClosedTypeDoesNotSatisfyNewGenericConstraint
Exception messages: System.ArgumentException : Generic implementation type 'Microsoft.Extensions.DependencyInjection.Specification.Fakes.ClassWithStructConstraint`1' has a DefaultConstructorConstraint ('new()' constraint), but the generic service type 'Microsoft.Extensions.DependencyInjection.Specification.Fakes.IFakeOpenGenericService`1' doesn't.
4) [FAIL] Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactoryTest.CreateCallSite_ReturnsService_IfClosedTypeSatisfiesNewGenericConstraint
Exception messages: System.ArgumentException : Generic implementation type 'Microsoft.Extensions.DependencyInjection.Specification.Fakes.ClassWithNewConstraint`1' has a DefaultConstructorConstraint ('new()' constraint), but the generic service type 'Microsoft.Extensions.DependencyInjection.Specification.Fakes.IFakeOpenGenericService`1' doesn't.
First build it occurred
First observed (within the scanned window) in build 1399212, which finished on 2026-04-28T07:31:50Z (commit 2ac6372).
Note: This window represents the last ~8 days of builds. The true origin may be earlier.
Occurrences in scanned window: Present in mobile library test jobs in the most recent build (multiple test failures in the same assembly).
Recommended action
Area owner: @dotnet/area-extensions-dependencyinjection should investigate why ValidateTrimmingAnnotations in CallSiteFactory is rejecting valid constraint combinations on mobile platforms.
Root cause: The validation logic at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.ValidateTrimmingAnnotations appears to be enforcing exact constraint matching between service interface and implementation type. This is incorrect — implementations are allowed to have stricter (more specific) constraints than their interfaces.
For example, if IService<T> has no constraints and Service<T> : IService<T> where T : struct, new(), this should be valid. The implementation's constraints are a subset of valid type arguments, which is safe.
Investigation steps:
Locate ValidateTrimmingAnnotations in src/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceLookup/CallSiteFactory.cs
Check if the validation logic differs on mobile platforms (e.g., due to platform-specific compilation symbols or trimming mode)
Review recent changes to the constraint validation logic
Verify that desktop platforms don't hit this validation (or that they skip it via a different code path)
Expected fix: Update ValidateTrimmingAnnotations to allow implementation types to have constraints that are a superset (more restrictive) of the service type's constraints. The validation should only fail when the implementation's constraints are less restrictive than required by the service interface.
Note
🔒 Integrity filter blocked 3 items
The following items were blocked because they don't meet the GitHub integrity level.
#125825search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#56828search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#29927search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
To allow these resources, lower min-integrity in your GitHub frontmatter:
Reasoning
Microsoft.Extensions.DependencyInjection.Testsis failing on mobile platforms (iOS, tvOS, macCatalyst, Android) with errors related to generic constraint validation. The DI container'sValidateTrimmingAnnotationsmethod is incorrectly rejecting implementations that have anew()constraint when the service interface doesn't have one.The error states:
This validation is overly restrictive. An implementation can have more constraints than the interface it implements — that's valid and safe. The constraint on the implementation guarantees that any type argument passed will satisfy the implementation's needs, which includes satisfying the less-restrictive interface. The validation logic appears to be requiring exact constraint matching instead of allowing implementation constraints to be a superset of interface constraints.
This is a product bug in the DI container's constraint validation logic, not a test issue. The same tests pass on desktop platforms.
Impact on platforms
Failing on all tested mobile platforms in build 1399212 (2026-04-28):
Errors log
From maccatalyst-arm64 Helix work item
Microsoft.Extensions.DependencyInjection.Tests(console log):First build it occurred
First observed (within the scanned window) in build 1399212, which finished on 2026-04-28T07:31:50Z (commit 2ac6372).
Note: This window represents the last ~8 days of builds. The true origin may be earlier.
Occurrences in scanned window: Present in mobile library test jobs in the most recent build (multiple test failures in the same assembly).
Recommended action
Area owner:
@dotnet/area-extensions-dependencyinjectionshould investigate whyValidateTrimmingAnnotationsinCallSiteFactoryis rejecting valid constraint combinations on mobile platforms.Root cause: The validation logic at
Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.ValidateTrimmingAnnotationsappears to be enforcing exact constraint matching between service interface and implementation type. This is incorrect — implementations are allowed to have stricter (more specific) constraints than their interfaces.For example, if
IService<T>has no constraints andService<T> : IService<T> where T : struct, new(), this should be valid. The implementation's constraints are a subset of valid type arguments, which is safe.Investigation steps:
ValidateTrimmingAnnotationsinsrc/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceLookup/CallSiteFactory.csExpected fix: Update
ValidateTrimmingAnnotationsto allow implementation types to have constraints that are a superset (more restrictive) of the service type's constraints. The validation should only fail when the implementation's constraints are less restrictive than required by the service interface.Note
🔒 Integrity filter blocked 3 items
The following items were blocked because they don't meet the GitHub integrity level.
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".To allow these resources, lower
min-integrityin your GitHub frontmatter: