Feature request: Allow win2d.uwp and win2d.winui to co-exist

[HO-COOH]

In WinUI3, the SystemBackdrop of a Microsoft.UI.Xaml.Window accepts a Windows.UI.Composition.CompositionBrush in its ICompositionSupportsSystemBackdrop parameter. See this

void OnTargetConnected(winrt::Microsoft::UI::Composition::ICompositionSupportsSystemBackdrop const& connectedTarget, winrt::Microsoft::UI::Xaml::XamlRoot const& xamlRoot)

Doing anything non-trivial requries the win2d.uwp package, which would conflict with win2d.winui package. Please make them compatible.

[getrou]

Using win2d.uwp and win2d.winui in the same app is not supported right now.

This is mostly because combining WinUI3 and UWP XAML in one process is not supported. Both WinUI3 and UWP Xaml use the namespace/binary/winmd name Microsoft.UI.Xaml, which would conflict with one another.

Win2d.uwp depends on UWP Microsoft.UI.Xaml and win2d.winui depends on WinUI3 Microsoft.UI.Xaml, so you cannot have both in the same process right now.

In the future, we might be able to do the following to enable this scenario.

• Split both win2d.uwp and win2d.winui into two components each (either two packages each or one package each with two binaries).
  • win2d.base contains all the non-XAML code (including the code you want to use with the ICompositionSupportsSystemBackdrop)
  • win2d.xaml replaces the existing packages and contains all the XAML code, and depends on win2d-base
• We would also have to rename the binaries/winmds in the UWP/WinUI packages so that they are different and don't conflict

This would be a very large change, and right now we don't plan on doing this work in the immediate future. However, I'll raise this issue again with the team using your example here and add it to the list of good reasons to do this work.

[Sergio0694]

As a temporary workaround, a solution could also be to put all your code to create whatever custom effect you want there into a separate WinRT component (either C++, or C# compiled with NativeAOT, etc.). Then just load that and use that to create your effects. That WinRT component would only reference Win2D.uwp, and it would handle creatin the correct brush and everything else needed. It'd just expose an API for you to get that brush, so there wouldn't be namespace conflicts.

I understand it would add a bit of complexity, binary size and memory use but it could solve your issue for now 🙂

[HO-COOH]

As a temporary workaround, a solution could also be to put all your code to create whatever custom effect you want there into a separate WinRT component (either C++, or C# compiled with NativeAOT, etc.). Then just load that and use that to create your effects. That WinRT component would only reference Win2D.uwp, and it would handle creatin the correct brush and everything else needed. It'd just expose an API for you to get that brush, so there wouldn't be namespace conflicts.

I understand it would add a bit of complexity, binary size and memory use but it could solve your issue for now 🙂

I already tried referencing win2d.winui in the main project + a WinRT component that referencing win2d.uwp, it does NOT work. It simply exceptions out