New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WPF Conversion issue to .NET Core 3.1 #3280
Comments
Editing my answer out to avoid confusion sorry. I had a really shaky recollection of the timelines of the various work done around this. @vatsan-madhavan made a workaround here: #765 (comment) I believe this is still valid. |
This worked. Thanks! It would be nice if this gets documented or merged as an official solution for 5.0 |
I am getting same issue after migrating WPF component to .net5.0-windows, is it fixed now or we still need go with workaround? error CS0433: The type 'DataGridHeaderBorder' exists in both 'PresentationFramework.Aero, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' and 'PresentationFramework.Aero2, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' |
We are converting a large commercial WPF application over to .NET Core 3.1 and have run into a problem that I'm not sure how to resolve.
error CS0433: The type 'ListBoxChrome' exists in both 'PresentationFramework.Aero, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' and 'PresentationFramework.Aero2, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
This error happens in .NET Core because by default it pulls in ALL of the WPF assembles as references. Unfortunately, both PresentationFramework.Aero and PresentationFramework.Aero2 assemblies define the same class under the same namespace.
Our xaml namespace looks like this:
xmlns:mwt="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero"
I'm assuming the issue is that the C# generated by the "code-behind" process for our xaml, has no way of distinguishing which assembly this comes from as both assemblies use the same namespace.
In .NET Framework, this was never an issue because you had control over which assemblies were referenced by your projects.
How does one workaround this?
Thanks much,
James
The text was updated successfully, but these errors were encountered: