Skip to content
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

Proposal: Make WinUI 3 usable from third party host applications (and non-WinUI 3 first party assemblies) #9359

Open
myth384 opened this issue Feb 22, 2024 · 3 comments
Labels
feature proposal New feature proposal

Comments

@myth384
Copy link

myth384 commented Feb 22, 2024

Proposal: Make WinUI 3 usable from third party host applications (and non-WinUI 3 first party assemblies)

Summary

WinUI 3 needs an effortless way to instantiate new WinUI 3 Windows, both modal and modeless, from plug-in type applications for third party host applications and non-WinUI 3 first party assemblies.

Rationale

  • WinUI 3 is the way forward for desktop development, but that should be for every use case.
  • We shouldn't have to rely on other frameworks (WPF/Uno Platform) to be able to show WinUI 3 controls inside XAML islands.
  • Multiple plug-ins using WinUI 3 should not conflict with each other in any way.
  • This proposal also covers other use cases, like using WinUI 3 from first party assemblies using other UI frameworks.

Scope

Capability Priority
WinUI 3 Application object can be isolated inside an AssemblyLoadContext, if isolation is not provided by the host application Must
References and Resources from XAML respect the path defined in the AssemblyLoadContext Must
Multiple isolated Application objects can coexist inside an Appdomain Must
The Applications objects can be started, without blocking the host application Must
New WinUI 3 Windows can be opened modal and modeless Must
Xaml Islands can coexist with the proposed solution Should

Important Notes

Currently there is no easy way to implement WinUI 3 in plug-in type applications for a third party host application, like multiple Autodesk and Microsoft Office products. I tried so many ways, but most of the time I had to conclude I entered a cul-de-sac. My current workaround is to use a WinUI3 UserControl with all contents, hosted by a single UnoXamlHost placed inside a WPF Window.
Typically, these plug-ins are (COM interop) class libraries instantiated by the host application and need direct access to objects exposed by host API. I think it is safe to assume most host applications don't use AssemblyLoadContext yet, if ever. Isolation could still be achieved by implementing AssemblyLoadContext at the plug-in side.

Open Questions

@myth384 myth384 added the feature proposal New feature proposal label Feb 22, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issue needs to be triaged by the area owners label Feb 22, 2024
Copy link

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you!

Open similar issues:

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

@myth384
Copy link
Author

myth384 commented Feb 24, 2024

FYI: Avalonis UI's AppBuilderBase<TAppBuilder> class has the method SetupWithoutStarting() for the discribed use case. After calling this method, new Windows can be shown without blocking the host application.

@jozefizso
Copy link

This would help us create Office COM add-ins with modern user interface.

The COM add-ins are hosted in the Office apps and we need a way to initialize the WinUI in a host app outside of our control.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature proposal New feature proposal
Projects
None yet
Development

No branches or pull requests

3 participants