Ok, this is a weird one, but bear with me. We use WPF user controls inside a Forms WpfElementHost to implement WPF-based panels for our plug-ins. This has been implemented years ago before Eto was packaged with Rhino. Some of the WPF-based panels use the Xceed.Wpf.Toolkit.DoubleUpDown control for numeric input. For that I distribute copies of the Xceed Wpf Toolkit assemblies.
While working on a problem, I see that instances of the DoubleUpDown control do not come from the distributed tool kit assembly. Rather, they come from a runtime module that belongs to Eto.Wpf.dll. I suspect that the XAML loader attempts to resolve the Xceed.Wpf.Toolkit assembly, finds that Eto has already loaded it using a runtime module and uses that, rather than the distributed DLL’s. The problem I’m facing is that I cannot use dependency property resolution because of assembly conflicts (the dependency property of the distributed assembly cannot be resolved on an instance from the runtime module).
It would be nice if Eto.Wpf.dll just had a normal dependency on Xceed.Wpf.Toolkit, rather than this unexpected runtime module approach. That way, any controls that want to use Wpf directly while Eto.Wpf is loaded do not get switched over to the Eto runtime module.
@curtisw Do you have any tips how to handle this?