CsWinRT

CsWinRT copied to clipboard

Filing this here to track a dependency on cswinrt from https://github.com/microsoft/react-native-windows/issues/6539 We would like to be able to move away from C# UWP but we still need to target system xaml. So we would like the ability for cswinrt to target UWP apps and system XAML so that we can avoid a whole bunch of issues related to .net native and consuming nugets from C++ apps.

Related: https://github.com/microsoft/react-native-windows/issues/6539

This would require custom type mapping for xaml to map onto inbox System XAML. Right now the custom type mappings go against WinUI.

I'm a little surprised that C#/WinRT doesn't already support system XAML. Just a noob here, but I had assumed that "lifting this projection support out of the compiler and runtime" would also entail decoupling from WinUI. Are there technical reasons why it can't/won't be done?

Also this will unblock the XAML islands on .NET 5+ scenario, without this we'll have to wait for WinUI 3 XAML islands which is "scheduled to a later release".

I have a component that exposes a few platform XAML types. Before I could just use them from C# but now with C#/WinRT, it blacklists all those types from the projection, unlike every other WinRT projection. Even if you reserve certain mappings to Microsoft.UI.Xaml (eg: INotifyPropertyChanged), Windows.UI.Xaml types must be available even if you have Microsoft.UI.Xaml (from WinUI 3) referenced. C#/WinRT shouldn't be framework dependent. If you don't want people from using types from Windows.UI.Xaml, you should add a deprecated attribute (at least in the C#/WinRT projection), instead of not projecting them entirely.

@angelazhangmsft This issue is hanging on thin air and should be dropped right away.

UWP/CoreWindow was doomed to oblivion a loooong time ago. As .NET 5 / .NET 6 / .NET 7 and upwards versions themselves will never support it , CsWinRT can't do very much, can it ?

.NET 5 / 6 / 7 won't be compatible with AppContainer and UAP-only environments anytime soon, so UWP is not actually relevant here. This is mainly for XAML islands.

so the title be modified to reflect XAML Island only. (Support for ~~UWP and~~ System XAML for XAML Islands.

<RE> well contrary to MS marketing, AppContainer is not tied to any Window specific tech (CoreWindow aka UWP)</RE>

I don't think that it is necessary, you can actually create UWP apps with .NET 6, however the incompatibility with System XAML in stock C#/WinRT blocks that.

(see https://github.com/gus33000/CsUWP)

That sounds like great news, I am always baffled by the lack of XAML islands support in .NET 5/6.

For those are interested, @gus33000's fork of CsWinRT is at https://github.com/gus33000/CsWinRT/tree/wux.

There are some roadblocks at the moment for having both Windows.UI.Xaml and Microsoft.UI.Xaml support in CsWinRT, which is why I haven't tried to do a PR yet for this. Mainly you have interop classes for .NET/WinRT that can currently only be applied to Windows.UI.Xaml or Microsoft.UI.Xaml. (As an example, CollectionChanged) It would be a bit messy at the moment to have support for both in the code. Maybe someone has an idea in order to make this a bit better?

There are some roadblocks at the moment for having both Windows.UI.Xaml and Microsoft.UI.Xaml support in CsWinRT, which is why I haven't tried to do a PR yet for this. Mainly you have interop classes for .NET/WinRT that can currently only be applied to Windows.UI.Xaml or Microsoft.UI.Xaml. (As an example, CollectionChanged) It would be a bit messy at the moment to have support for both in the code. Maybe someone has an idea in order to make this a bit better?

Is there any specific reason why WinUI 3 needs C#/WinRT coupling? If no then I think the best approach is to just remove that coupling.

@gus33000 Most of the types eg: CollectionChanged are very similar across both WinUI 2.x and WinUI 3 so those can be projected as the same type while other types will be projected separately.

This should definitely be addressed because .net core 3.1 is going out of support by the end of the year and I doubt that winui 3 will be a good replacement for it by that time.

C#/WinRT 1.6.1 should already support building projections for system XAML, however building projections for libraries like the XamlApplication Toolkit or WinUI 2 causes the "class not registered" exception.

Mainly you have interop classes for .NET/WinRT that can currently only be applied to Windows.UI.Xaml or Microsoft.UI.Xaml

I guess it should be fine to split CsWinRT into two libraries right? CsWinRT for the core WinRT projection, and CsWinRT.WinUI for XAML related stuff (with separated assembly for system XAML and WinUI 3 XAML).

Now with trimming working the worry of yet another DLL is not that relevant anymore.

Friendly reminder: .NET Core 3.1 is now EOL, there is no officially supported way to use XAML islands on .NET now.

Maybe someone has an idea in order to make this a bit better?

How about adding a new property (i.e. CsWinRTXamlNamespace), like C++/WinRT is currently doing? Of course, the property would be set to Microsoft.UI.Xaml by default.

But rather unfortunately, WinRT.Runtime would not be able to know whatever we set here, which would be a dealbreaker. I can only think of shipping separate binaries of WinRT.Runtime: one for Microsoft.UI.Xaml and one for Windows.UI.Xaml.

How much code in WinRT.Runtime is dependent on the XAML implementation? Can we generate entire classes like C++/WinRT does and eliminate the issue all together?

It powers some XAML types, as well as properly managing some error codes.