Microsoft-ui-xaml: Proposal: Allow for shared WinUI 3.0 control libraries that can be used in either UWP or win32

[matthew4850]

Proposal: Allow for shared WinUI 3.0 control libraries that can be used in either UWP or win32

Summary

It would be nice to have a shared library type for win ui 3.0 that would allow for creation of custom controls that can be shared between UWP and win32.

Rationale

• This would make it easy to target both UWP and win32
• This would allow nuget packages that contain winui controls to work on both UWP and win32

[stevenbrix]

At a minimum I think developers should be able to accomplish the following:

1. Easily share code between a WinUI library that is built for both WinUI Desktop and WinUI UWP
2. Produce a Nuget that contains both

A project type that does this would be ideal. If we don't get that, then at least a well documented blog post on how to achieve this.

[ranjeshj]

@marb2000 as FYI

[michael-hawker]

This would be invaluable for the Windows Community Toolkit. We plan to port over to WinUI 3, so if we could easily ensure that the majority of our controls could work in both landscapes, that'd be a huge win for everyone.

I honestly was just kind of expecting this to be the case and work for anything built on-top of WinUI 3; so glad it's being called out specifically as it'd be good to know the details.

FYI @azchohfi @onovotny

[Gavin-Williams]

What do you mean here with Win32? Do you mean .Net Standard, .Net Core or C++/Win32 (legacy C style app)?

There shouldn't be an app platform that isn't universal. So really, Win32 should be removed from Windows and UWP/WinRT app model should be extended to run both in the UWP container and as an unrestricted application. That would be the best way to universalize WinUI, do we really want to keep the C style Windows app around?

The way I see Xaml Islands is as a pathway for Legacy devs to move forwards to UWP (Or the Windows Platform as it will be called). Using islands they can already employ WinUI. So do you mean without Islands?

[prayaas-a]

@Gavin-Williams WinRT wasn't a complete rewrite. It's a subset of Win32 and depends on it. You can't "remove" Win32. Older parts of it could be deprecated, APIs replaced. Further, there are many Win32 APIs that have no convenient UWP replacement yet and need work.
WinUI 3 will allow WinForms, WPF, and MFC developers to support a modern UI. None of those platforms are "universal" and it looks like they'll be here to stay for now.
WinRT definitely needs more work as a platform including feature parity with WPF (and desktop APIs including file access which is much easier in winforms/wpf) before it can get .NET devs to port codebehinds, let alone legacy native Windows apps. WinUI will at least allow them to change the UI part of it.

[StephenLPeters]

@marb2000 maybe you can weigh in here? @jesbis fyi.

[Gavin-Williams]

You can't "remove" Win32

This is a bit off topic, but my view is that MS should be trying to bring Windows developers onto a common app model and api surface. Which relates to the OP in that it pushes for continuing support of two different application platforms.

I don't mean get rid of all Win32 API's. I mean that the Win32 application models, templates, input API's, graphics API's (GDI+) and probably a few more things, should be removed from Windows and Visual Studio. When a developer sits down in 2021 to write a Windows desktop app/game they shouldn't have the choice for legacy app stubs - they should be forced to write against the Universal Windows Platform - whether they use C++ or C# ( on .net 5). They can call into Win32 API's if they need certain functionality (can't think of anything useful but there must be stuff that people still use - there's a lot of apps out there).

A big problem i think is that there are too many greenfield projects choosing C style win32 and .net framework winforms app templates just because they are traditional models, and that's what educators push, not because they are the best choice today and moving forward. Look at HandmadeHero or TheCherno for examples of educators pushing legacy app platforms.

WinRT and WPF are not the same kind of thing. WPF is a UI platform, it runs on .net framework, WinRT is a complete system platform and API surface - it is utilized and consumed by both C++ and C# (via .net core or uwp apps - and by .net 5 in the future).

WinForms and WPF are indeed universal (or will be) now that they run on .net core - and eventually .net 5. That is they will run on all Windows 10 devices.

And how is reading and writing files with UWP more difficult? I don't get this claim. Are you talking about folder access restrictions? Full system access is being wound back in Windows - for good reason. I'm still not convinced that UWP needs wider access. It gives access to the user folders. Can anybody explain to me why I would want an app to have access to the system drive?

[Felix-Dev]

@Gavin-Williams This is indeed getting off-topic for this specific proposal. I would kindly suggest issue https://github.com/microsoft/microsoft-ui-xaml/issues/1856 to you where you can voice your view on Win32 vs UWP and how they should be treated by Microsoft going forward. There are fundamental UWP API gaps around which will force devs to currently write apps based on the Win32 app model and the linked thread above should cover this type of discussion and how UWP needs to be further improved. (Might as well just re-post your above post there.) Much appreciated 🙂

[sonnemaf]

Is there any progress on this subject. I would love to be able to create a ClassLibrary with my WinUI3 controls and pages which could be referenced from a Win32 and a UWP (WinUI) project. @michael-hawker must have the same problem with the Toolkit. Is there a workaround using MSBuild.Sdk.Extras. Maybe @clairernovotny can help?

I think that having 2 different WinUI templates for Class Libraries is wrong. There should only be one.

[StephenLPeters]

@alwu-msft or @stevenbrix fyi

[alwu-msft]

@sonnemaf That's definitely a goal, but unfortunately it is unlikely we will be able to deliver that for WinUI 3 as it will require support from .Net 5 for UWP apps (which currently use .Net Native).

[azchohfi]

We are multitargeting in the Windows Community Toolkit, but that is only an experiment for now:
https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/winui_multitarget
Example:
https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/winui_multitarget/Microsoft.Toolkit.Uwp.UI.Controls/Microsoft.Toolkit.Uwp.UI.Controls.csproj

It is working quite ok, but we had to fix some things. This is the main commit:
https://github.com/windows-toolkit/WindowsCommunityToolkit/commit/f21603d2aed556055f3975b8e9802f46bc771a43#diff-f9adf49008797675a045b84d15fcedc7

When moving from UWP -> WinUI3 Desktop we removed MSBuild.Sdk.Extras, and for the multitargeting we had to add it back, and you can see all the #if WINDOWS_UWP all arround.

[sonnemaf]

@azchohfi I tried to get the multitargeting solution working. Didn't succeed though. This must be made simple. You really need a Solution template for this. It is just too difficult. I suggest spending some time on developing this template. WinUI needs this to get accepted.

[michael-hawker]

@sonnemaf I think the crux of this issue is the .NET 5 story. It's the same problem. Once everything is aligned on .NET 5, this should just work. That's why we've migrated our previews in the WCT to .NET 5 for WinUI 3 Desktop and focusing on the previews there.

@ryandemopoulos getting to .NET 5 for both Desktop and UWP should be part of the release criteria for 3.0. It's going to be too painful for library developers otherwise to try and support both, especially when certain mappings don't work with WinUI 3 + .NET Native.