Describe the bug
Starting in 4.2.1, Wpf.Ui.Controls.TextBlock registers its attached/dependency properties against the framework owner type typeof(System.Windows.Controls.TextBlock) instead of its own type typeof(Wpf.Ui.Controls.TextBlock) (as it did in ≤ 4.2.0).
Because WPFs DependencyProperty registry is process-global and keyed by (propertyName, ownerType), and System.Windows.Controls.TextBlock is a single shared framework type, a second copy of Wpf.Ui loaded anywhere in the process throws when its TextBlock static constructor runs:
System.ArgumentException: 'FontTypographyStyle' property was already registered by 'TextBlock'.
at System.Windows.DependencyProperty.RegisterCommon(...)
at Wpf.Ui.Controls.TextBlock..cctor()
This makes Wpf.Ui unusable in any host that loads plugins into separate AssemblyLoadContexts where two plugins ship Wpf.Ui (Autodesk Inventor 2027 add-in isolation, Revit, AutoCAD, and any custom ALC-based plugin system).
This is likely not limited to TextBlock Any control changed to register against a framework base type in 4.2.1+ would have the same effect. TextBlock is the one confirmed here.
Im not sure if I fully understand it yet, but currently all my addins that are loaded in the same process need to have the same library version and no AssemblyLoadContext should be used, which is not a solution. Especially because I dont controll other addins that might be added. I know that is probably a pretty unique problem im facing but im wondering why this change was done and if maybe others face the same problem?
To Reproduce
WpfUiAlcRepro.zip
Switch the version to 4.2 in the csproj and it works fine. With 4.3 currently configured it wont work.
Expected behavior
It should be possible to have different wpfui version in a process.
Screenshots
No response
OS version
Windows 11 with Inventor 2025 / 2026 / 2027 but reproducable with a simple console app.
.NET version
Tested with Net8.0
WPF-UI NuGet version
4.20
4.2.1
4.3.0
Additional context
No response
Describe the bug
Starting in 4.2.1,
Wpf.Ui.Controls.TextBlockregisters its attached/dependency properties against the framework owner typetypeof(System.Windows.Controls.TextBlock)instead of its own typetypeof(Wpf.Ui.Controls.TextBlock)(as it did in ≤ 4.2.0).Because WPFs
DependencyPropertyregistry is process-global and keyed by(propertyName, ownerType), andSystem.Windows.Controls.TextBlockis a single shared framework type, a second copy ofWpf.Uiloaded anywhere in the process throws when itsTextBlockstatic constructor runs:This makes Wpf.Ui unusable in any host that loads plugins into separate
AssemblyLoadContexts where two plugins ship Wpf.Ui (Autodesk Inventor 2027 add-in isolation, Revit, AutoCAD, and any custom ALC-based plugin system).This is likely not limited to
TextBlockAny control changed to register against a framework base type in 4.2.1+ would have the same effect.TextBlockis the one confirmed here.Im not sure if I fully understand it yet, but currently all my addins that are loaded in the same process need to have the same library version and no AssemblyLoadContext should be used, which is not a solution. Especially because I dont controll other addins that might be added. I know that is probably a pretty unique problem im facing but im wondering why this change was done and if maybe others face the same problem?
To Reproduce
WpfUiAlcRepro.zip
Switch the version to 4.2 in the csproj and it works fine. With 4.3 currently configured it wont work.
Expected behavior
It should be possible to have different wpfui version in a process.
Screenshots
No response
OS version
Windows 11 with Inventor 2025 / 2026 / 2027 but reproducable with a simple console app.
.NET version
Tested with Net8.0
WPF-UI NuGet version
4.20
4.2.1
4.3.0
Additional context
No response