How to create optional package in WinUI3 project ?

[Osirisoo0O]

No template and no document.
I need help.
thanks.

[DarranRowe]

At the very least, have you tried to adapt the information given in the Optional Packages documentation?
Since the majority of the optional package stuff is controlled by the packaging side of things, then I would imagine that the optional package steps are unrelated to WinUI 3 and just following the MSIX steps should be enough.

[Osirisoo0O]

In .NET 6 ,you can't use .winmd.
On the other hand,I have some problem about WinRT Component created by CsWinRT has exception 0x80040154 CLASSNOTREG.
I want to build a plug-in system,then I can update function package without main app.
Thanks for reply.

[DarranRowe]

Hence why I state adapt.
While you can't directly use a .winmd file, you can create a projection from a .winmd file using CsWinRT.

[Osirisoo0O]

I tryed.But it's not as expected.
Projection need dll. I don't want that.

[DrusTheAxe]

You can use Optional packages but I recommend looking into Dynamic Dependencies

Optional packages support code if they're in a RelatedSet (if they're not your main package can't access code in them. Makes not-RelatedSet Optional packages great for WordArt and other data-only assets but not so much for code like plugins). If memory serves to be part of a RelatedSet requires packages be in the same MSIX Bundle. That's great when you have tightly integrated code you sliced up into multiple optional parts (think "game DLC") but less so when you have a plugin extensibility model.

Dynamic Dependencies lets you dynamically add packages to your package graph at runtime. This is to MSIX packages as the moral equivalent of LoadLibrary is to DLLs - you can know nothing about a target at build-time and at runtime call an API to dynamically get access to that thing you didn't know about at build-time but want to access.

A popular combination is to use <Extension Category="windows.appExtension"> for your plugin to 'advertise' it exists and supports your extensibility model. You use the AppExtensionCatalog API to enumerate such things then use the Dynamic Dependencies API to add them to your package graph so you can access them (be it LoadLibrary(), ActivateInstance(), Assembly.Load() or whatever).

Another option some folks have used is AppExtension for the advertising facet and out-of-proc Packaged COM for the code construct. OOP Packaged COM objects are identified with a coclassid (GUID) in the classic COM way and, like the classic COM way, are visible across all apps. The implementation details differ but it's akin to registering your classic COM object in HKCU - yes, all apps running as the user can see and use them, but it's also a Highlander solution (ThereCanBeOnlyOne!) and last writer wins so if you have 2 revs of a COM object the last one installed will be 'the' copy seen by calls to CoCreateInstance().

[visionarylab]

Agree with @DrusTheAxe mention. However, if native .NET even asp.net support the .net plugin system or similar like Chrome extension, it would eliminate a lot of zeroday security issue. Most people also won't have deep understanding of .net internal (Equivalence of V8 sandbox on Chrome). If .NET hosting another .NET plugin, is a bit more security challenging, there could be other safer language for plugin development etc...

Official support would pave a lot of way for the community. Especially official example and scenario, like to use .net's plugin on WinUI3 .NET plugin support

WinUI3-plugin-sample

Blazor JS Interop