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
fix(hosting): chain entry-assembly and registered XAML metadata providers (#144)
* fix(hosting): chain entry-assembly and registered XAML metadata providers
WinUI's lifted XAML loader resolves `local:` namespaces and Generic.xaml
type/property references through `Application.Current`'s
`IXamlMetadataProvider` chain. `ReactorApplication` previously only
delegated to Reactor's own generated provider plus a hand-written core
stub, so any custom `Control` declared in the consuming app — or in a
referenced third-party library when the consumer has no XAML of its
own — went unresolved, and the lifted parser took the process down with
a `Failed to create a 'Microsoft.UI.Xaml.DependencyProperty' from the
text 'MyText'` originate error before the control could render.
Two-part fix:
1. Auto-discover the entry assembly's XAML-compiler-generated
`XamlMetaDataProvider` and chain it between Reactor's provider and the
core stub. Covers the common case where the consumer has any XAML
file (which transitively chains every referenced library through the
compiler-generated `OtherProviders` list).
2. Add `ReactorApp.RegisterControlAssembly(IXamlMetadataProvider)` and
`RegisterControlAssembly(Assembly)` for the no-XAML-consumer case,
where there is no compiler-generated chain to ride. Idempotent,
thread-safe, copy-on-write snapshot semantics so the hot lookup path
needs no locking. Mirrors the documented Win2D / CommunityToolkit
pattern in pure WinUI apps.
Selftests: `Issue142_CustomControlPrivateDp_Renders` exercises path 1 via
a control declared in the host project; `Issue142_ThirdPartyControlPrivateDp_Renders`
exercises path 2 via the new `Reactor.AppTests.ThirdPartyControls`
library that simulates a real 3P control NuGet.
Fixes#142
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(hosting): use OfType<Type>() in FindXamlMetadataProviderInAssembly
Addresses #144 review feedback. `ex.Types` is `Type?[]`, so the previous
`.Where(t => t is not null).ToArray()!` pattern relied on a nullable
suppression and left a redundant `t is null` check inside the scan loop.
`OfType<Type>().ToArray()` produces a true `Type[]`, eliminating both.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
/// Convenience overload that locates the XAML-compiler-generated
87
+
/// <c>IXamlMetadataProvider</c> in <paramref name="assembly"/> (the type the
88
+
/// XAML compiler emits when the project has at least one XAML file) and
89
+
/// registers it. Throws if no such provider is found — pass the
90
+
/// <see cref="IXamlMetadataProvider"/> instance directly if your library
91
+
/// uses a non-standard provider type.
92
+
/// </summary>
93
+
[UnconditionalSuppressMessage("Trimming","IL2026",Justification="Caller-supplied assembly's XAML metadata provider is preserved by the XAML compiler that emits it.")]
94
+
[UnconditionalSuppressMessage("Trimming","IL2072",Justification="Parameterless ctor invoked on a freshly-discovered IXamlMetadataProvider type.")]
95
+
[UnconditionalSuppressMessage("Trimming","IL2075",Justification="Reflection over caller-supplied assembly types; XAML compiler preserves IXamlMetadataProvider implementations.")]
0 commit comments