Convert to UWP Class Library?

[hawkerm]

Not sure how much we're really benefiting from being a Windows Runtime Component. Plus it means we can't use Task as a return type in our signatures which makes some of the Providers weird to use with having to wrap returns in the AsyncInfo.Run pattern.

It'd be worth thinking about making this jump in the future and cleaning this up a bit?

[hawkerm]

This would also let us use abstract base classes in the library for the CssStyles...

[hez2010]

Being a pure UWP class library means that monaco-editor-uwp won't be able to use in UWP which is written in C++/WinRT.
My opinion is that monaco type bindings and classes which don't need to be exposed can be convert to a class library, and still keep the control itself and other parts a Windows Runtime Component.

[hawkerm]

@hez2010 are you using it from C++ currently? I'm not sure what the audience for that usage is.

Also, even if it's a class library you can include it from another C# component utilized by C++ project, so there's a workaround to access it still, though a bit more indirectly. There's just a lot of restrictions which come with being a pure Windows Runtime Component.

[hez2010]

I'm not sure what will happen exactly if we convert it to a UWP class library, but seems that it worth a try.

[michael-hawker]

Just noticed this remark: https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.webview.addweballowedobject#remarks

The object passed into AddWebAllowedObject must be imported from a Windows Runtime component that is separate from the app assembly.

Not sure if this will be the case still for WebView2?

[michael-hawker]

🦙 Cross-ref microsoft/microsoft-ui-xaml#2571