XAML Designer rise an exception while creating ChromiumWebBrowser in XAML

[DrCQ]

I use CefSharp (V114.2.100) to create an ChromiumWebBrowser instance in the XAML code. The execution of the application has no errors, but the XAML Designer (VS 17.6.4) is rising an exception:
Parameter "parameter" (object) cannot be of type Microsoft.VisualStudio.XSurface.Wpf.Window, as the command type requires an argument of type System.Windows.Window. (Parameter 'parameter')

I contacted Microsoft Support but without proper response yet!

The XAML code causing this exception is part of a Button binding command:
CommandParameter="{Binding Mode=OneWay, RelativeSource={RelativeSource AncestorType={x:Type local:MainWindow}}}"

During my investigation, I found the following hint from VS: Cannot load a reference assembly for execution

Any idea why the XAML Designer cannot find the proper assembly, while the execution (Debug and Release mode) is running without any problems?
You can find the demo application here with only few lines of XAML and VB code.
Regards,

Christoph

[amaitland]

For background CefSharp uses VC++. Specifically CefSharp.Core.Runtime.dll is a mixed mode C++/CLI assembly. In the NETCore package there is a ref assembly which is used for compilation with the the actual arch specific dll being used at runtime.

The package structure is described at #2796 (comment)

With the old .Net Framework designer we used to specifically avoid loading any reference to CefSharp.Core.Runtime.dll when in design mode. I've not spent any time looking into how NetCore designers work for WPF. I know WinForms added a new OOP designer to workaround the issue of VS being written in .net 4.8 and subsequently being unable to load a NetCore assembly. Did WPF do something similar?

Does the WPF designer have it's own output window in VS? There might be some more detail as to what's going on there.

I contacted Microsoft Support but without proper response yet!

MS are likely the best qualified to diagnose/fix the issue. At best this would be something we'd have to workaround. The project provides a ref assembly which should be used in place of the arch specific assembly. If that's the actual problem.