Why is Windows 11's Dynamic Dependency API not available in WinRT?

[roxk]

(I know this is not the best place to ask this question, but this repository is where most of the discussion around dyndep happens and documented so I figured I might as well ask here)

In this doc, it is written that

1. Create an install-time reference
   ...
   ...call one of the following functions or methods to specify a set of criteria for the MSIX package that you want to use...
   Windows 11 (C/C++): TryCreatePackageDependency
   Windows App SDK (C/C++): MddTryCreatePackageDependency
   Windows App SDK (WinRT): PackageDependency.Create

Why is Windows 11's dynamic dependency not available in WinRT, but only available in plain C? It means C++ devs have to suffer from C style API (not ergonomic), and C# additionally has to write interop boilerplate. Is it an omission in the doc or?

Thanks!

[DarranRowe]

Well, I'm not in a position to answer the why question since this would require someone from Microsoft to answer. There is also nothing in Windows.ApplicationModel in the latest canary SDK (Windows SDK 25387) to show that this exists or is currently in development.
One thing to remember is that it is pretty easy to wrap this. This repo has the implementation of the Windows App SDK version, so it can be used as a template for your own version. I think the biggest issue is figuring out how to store the install time references that use a filesystem or registry key. This could also be used as a template for a native C++ wrapper or a native C# wrapper too.
I want to reiterate that this isn't an attempt at an answer, but devs don't have to "suffer" if they don't want to.

[seven-mile]

Since WinRT is still not projected to most languages, it's the best option for Windows to export C API. Maybe in the future when WinRT is completely stable and usable, they choose to port WinRT-only API.

[jonwis]

@DarranRowe thanks - you're right that we don't publish every single IID in uuid.lib. Internally we use __uuidof() heavily.

I'd forgotten about the abi tool from xlang, thanks for the reminder! Does running abi.exe on Windows.WinMD metadata produce the constants you need?

I have this fever dream where the SDK contains only metadata, and everything is a set of projectors. Even static import libraries - just generate those on the fly from APIsets, no more worrying about kernelbase vs advapi vs whatever else. Auto-generate delayloads and presence-check methods for any ABI method. We'd_ probably cut the core install size of the SDK down by 30% or more, and we'd be more compiler-toolchain-agile. That's where we started with the CS/Win32 & WinMetadata & the Microsoft.Windows.SDK.* nuget packages. Maybe we'll continue on that path.

[DarranRowe]

@jonwis
Unfortunately, abi.exe doesn't do it either. All it generates is the same kind of external declaration, EXTERN_C const IID IID___x_ABI_CWindows_CFoundation_CIUriRuntimeClassFactory;, that is available in the Windows SDK headers.
This isn't the worst situation since the ABI headers also include the C++ definitions which also includes the IID. It just means that I would just define these values myself if I ever need to use the IID directly.

[DrusTheAxe]

This thread is asking why there isn't a Windows.ApplicationModel.* version of the dynamic dependency API. When we were doing design and review of this new API, we explicitly chose to put the C-style ABI into the platform SDK and to put a WinRT-based wrapper into the Windows App SDK. That's a path I'd like for us to continue on.

Ditto. It's been a very good path to follow and one I (continue to) recommend and advocate.

[DarranRowe]

@jonwis
I wrote a little script to generate all of the IIDs using midl and then compiling them into a library. This ended up at around 4MiB per platform, 7 for ARM64 if you include the EC symbols. So I completely understand why these aren't shipped with the SDK and why you want a more generative version of the Windows SDK.
Since I was trying it out, I also tried this method with the Windows App SDK. I generated the IDL files using winmdidl and then used midl to generate the IID files. This actually ended up with an interesting failure. I was getting errors along the lines of CrossSlidingState_Started already defined. Looking at the imports a little, microsoft.ui.input.idl imports windows.ui.core.idl, which in turn imports windows.ui.input.idl. Since midl doesn't seem to mangle the names of enumeration members to differentiate the scopes, this does end up with an error because the enumerations in Windows.UI.Input are mirrored in Microsoft.UI.Input. Windows.UI.Input and Microsoft.UI.Input aren't the only affected namespaces. That was just the first set of errors I saw. So unfortunately this means that using midl isn't a good general means of generating the IIDs for the C interfaces.
A little tool for reading the metadata and generating these IIDs would be useful for anyone wanting to use the C interfaces.

[jonwis]

Neato! Sounds like a fine tool to share if you're willing.

We do rely on namespaces heavily, especially where Microsoft.UI.* aims to replace/supplant Windows.UI.* types. For languages that support scope aliases it's not super hard to deal with - wui::CrossSlidingState vs mui::CrossSlidingState - but for languages without, life gets hard. Note how MIDL generates massively long interface names with the full namespace associated with them. Maybe in your tool, apply common shortenings or single-characters? Not super nice, but M_UI_CrossSliding vs WIN_UI_CrossSliding wouldn't be so horrible?

[DrusTheAxe]

I know this is not the best place to ask this question, but

It's actually a pretty good place for it :-)

Why is Windows 11's dynamic dependency not available in WinRT

Not available yet but soon => DynamicDependencies: Use Win11 APIs if available #3704

There's some work remaining but given the interest I've shared some of the more stable bits. I have a more unstable build locally I'm fiddling with e.g. tests are blocked because the bootstrapper's not savvy yet. Working through the details.

The goal is for WinAppSDK's Dynamic Dependency API to delegate to the OS' DynDep API if available, else use its own implementation to equivalent end (aka polyfill). This will happen in the WinAppSDK C API so all calls of WinAppSDK's C and WinRT DynDep API will benefit (including those using the C# projection).

This has additional benefits, e.g. the DDLM packages are unnecessary (when the Win11 API's available). They're a workaround to make Windows DoTheRightThing(TM) e.g. not remove a package while dynamically in use. But Windows handles that now (when using the Win11 API). Likewise, WinAppSDK's DynDep only supporting unpackaged apps is a limitation of its implementation; we can lift that restriction using the Win11 API. You can see hints of this already in the draft PR, with more to come.

[sylveon]

Does that work address issues like #3242 while using the WASDK version of dyn deps? Otherwise this would cause inconsistent behavior downlevel (which kinda defeats the point of a polyfill). My current use case for dynamic dependencies is primarily to import WinUI 2, so at the moment I cannot do any sort of polyfilling.

[DrusTheAxe]

Does that work address issues like #3242 while using the WASDK version of dyn deps?

Depends on the root cause. I'll need to hunt up some WinUI and MRT experts to say more.

Otherwise this would cause inconsistent behavior downlevel (which kinda defeats the point of a polyfill). My current use case for dynamic dependencies is primarily to import WinUI 2, so at the moment I cannot do any sort of polyfilling.

Does your issue with WinUI2 + WinAppSDK DynDep + Win11? Your issue doesn't say what OS you're running on when it fails, only that WinUI2 + Win11 DynDep + Win11 works.

[sylveon]

Does your issue with WinUI2 + WinAppSDK DynDep + Win11?

I believe so yes.