Fix implicit conversion operators bypassed in property injection casts

[Copilot]

Generated property setters cast (PropertyType)value where value is object. This is a CLR reference cast that bypasses user-defined implicit/explicit operators, causing InvalidCastException when ClassDataSource<T> type T differs from the property type.

Approach

Rather than modifying source generators to emit two-step casts (which breaks when cached values are already converted), this PR adds runtime conversion fallbacks using CastHelper.Cast() before calling the generated setters. CastHelper discovers and invokes op_Implicit/op_Explicit operators via reflection at runtime, handling both known and unknown data source types.

Changes

• PropertyInjector (runtime conversion): Added ConvertPropertyValueIfNeeded() that uses CastHelper.Cast() at runtime when the resolved value's type doesn't match the property type. Applied to both source-generated and reflection injection paths. This handles all data sources — including custom ones where the source generator can't know the produced type at compile time.

• ObjectLifecycleService: Added the same ConvertPropertyValueIfNeeded() conversion in SetCachedPropertiesOnInstance, which sets cached property values on new test instances (e.g., during retries). Without this, cached values that haven't been converted would fail the generated setter's direct cast.

• Tests:

  • ImplicitOperatorPropertyInjectionTests — reproduces the original scenario (ClassDataSource<ImplicitDbFixture> on a required ImplicitDbContext property with an implicit operator).
  • RuntimeImplicitConversionFromCustomDataSourceTests — custom UntypedDataSourceGeneratorAttribute with implicit operator on source type.
  • RuntimeExplicitConversionFromCustomDataSourceTests — custom data source with explicit operator.
  • RuntimeImplicitOnTargetTypeConversionTests — implicit operator defined on the target type (not the source).
  • RuntimeStructImplicitConversionTests — struct (value type) with implicit operator, exercising the boxing/unboxing path.
  • RuntimeSameTypeNoConversionTests — same-type baseline verifying no regression when types already match.
  • RuntimeMethodDataSourceImplicitConversionTests — MethodDataSource returning a different type with implicit operator.

[thomhurst]

@copilot is there a way to make it work at runtime, even when the source generator doesn't know the type information? E.g. custom data sources that yield different results

[Copilot]

@copilot is there a way to make it work at runtime, even when the source generator doesn't know the type information? E.g. custom data sources that yield different results

Yes — in ad3c513 I added a runtime fallback in PropertyInjector. Before setting a property value, both the source-gen and reflection paths now check if the resolved value's type doesn't match the property type. When there's a mismatch, CastHelper.Cast() is called, which discovers and invokes op_Implicit/op_Explicit operators via reflection at runtime. This means custom data sources that yield unexpected types will still have their conversion operators invoked, even when the source generator has no type information.

[thomhurst]

@copilot you need to add thorough test coverage around the runtime conversion fallback

[Copilot]

@copilot you need to add thorough test coverage around the runtime conversion fallback

Added in 9263257. 6 new test classes covering runtime conversion scenarios:

• Custom UntypedDataSourceGeneratorAttribute with implicit operator on source type, explicit operator, and implicit operator on target type
• Struct (value type) with implicit operator — exercises boxing/unboxing path
• Same-type baseline — no conversion needed, verifies no regression
• MethodDataSource returning a different type with implicit operator

Also found and fixed a bug: ObjectLifecycleService.SetCachedPropertiesOnInstance was calling SetProperty with raw cached values without conversion. This was the real failure path — the source-generated two-step cast (PropertyType)(DataSourceType)value broke when the cached value was already converted. Reverted the source generator changes and now rely entirely on runtime CastHelper.Cast() in all three setter paths.

[claude]

Code Review

The approach here — adding a runtime conversion fallback via CastHelper.Cast() before calling the generated setter — is the right design. The source generator can't know at compile time what type a custom UntypedDataSourceGeneratorAttribute will produce, so a runtime fallback is the correct place to handle this. The fix for ObjectLifecycleService.SetCachedPropertiesOnInstance (applying the same conversion to cached values) is also a good catch. Test coverage is thorough across operator directions, value types, and data source varieties.

---

Issues

1. Duplicated ConvertPropertyValueIfNeeded — should live in CastHelper

ConvertPropertyValueIfNeeded is copy-pasted identically into both PropertyInjector and ObjectLifecycleService. These two static methods will inevitably drift. The method is a thin wrapper over CastHelper.Cast() and belongs there:

// In CastHelper:
public static object? CastIfNeeded(Type targetType, object? value)
{
    if (value is null) return null;
    if (value.GetType().IsAssignableTo(targetType)) return value;
    return Cast(targetType, value);
}

Then both call sites become CastHelper.CastIfNeeded(metadata.PropertyType, resolvedValue). This keeps the CastHelper as the single source of truth for all conversion logic and means trimming/AOT annotations only need to be applied once.

2. Missing [DynamicallyAccessedMembers] on targetType parameter

ConvertPropertyValueIfNeeded passes targetType into CastHelper.Cast(Type type, ...), which requires [DynamicallyAccessedMembers(PublicParameterlessConstructor | Interfaces | PublicMethods)] on its first argument. Rather than suppressing IL2067, the parameter should carry the annotation:

private static object? ConvertPropertyValueIfNeeded(
    object? value,
    [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor
        | DynamicallyAccessedMemberTypes.Interfaces
        | DynamicallyAccessedMemberTypes.PublicMethods)] Type targetType)

The IL2067 suppressions with justifications like "PropertyType is preserved through source generation or reflection discovery" are correct in practice, but annotations are preferable to suppressions when the annotation can flow naturally — they give the compiler and trimmer actual information rather than telling them to be quiet.

3. AOT correctness gap

In AOT mode, CastHelper.Cast() skips reflection-based conversions and falls back to returning the value unconverted (or throwing a helpful InvalidCastException). In the case where it returns unconverted, the generated setter (PropertyType)value will still throw InvalidCastException since CLR reference casts bypass user-defined operators.

The [UnconditionalSuppressMessage("AOT", "IL3050", Justification = "CastHelper handles AOT scenarios with proper fallbacks")] is technically accurate — CastHelper does handle AOT by throwing an informative error rather than silently corrupting state. But this means the fix does not work in AOT mode for custom data sources. That's an acceptable known limitation (the reflection path was never AOT-safe) but it should be documented, either in an XML doc comment or a code comment on the call site, so future readers don't assume it works everywhere.

4. Unnecessary re-conversion in retry paths

In SetCachedPropertiesOnInstance, the conversion is re-applied every time a new test instance is created (e.g., for each retry). The conversion will always produce the same result — the cached value type doesn't change between retries.

The better fix is to store the already-converted value in the cache at the point of first injection (PropertyInjector), so that SetCachedPropertiesOnInstance simply reads the correctly-typed value and applies it without any conversion. If the cache key stores the post-conversion object, the ConvertPropertyValueIfNeeded call in ObjectLifecycleService becomes redundant. This is a correctness simplification, not just a micro-optimization.

5. Unhelpful comment

// Convert the value if needed (same as above) in ObjectLifecycleService.cs:212 gives no useful information. It should either explain why the conversion is needed here (like the comment above it does) or be removed.

---

Minor

The test file RuntimeConversionPropertyInjectionTests.cs is long but well-structured. The inline data source attribute classes (ImplicitSourceDataSourceAttribute, etc.) are clear for their purpose. No issues there.

[thomhurst]

@copilot address the code reviews