Please remove WASDK Dynamic dependencies packaged app limitation

[Gaoyifei1011]

Please remove WASDK Dynamic dependencies packaged app limitation

---------------------------------------

请删除 WASDK 动态依赖项打包的应用程序限制

---

My project uses WinUI 2 and WinUI 3 together, WinUI 2 and WinUI 3 contain both Microshot.ui.xaml.dll dependency libraries, and I need to use the MSIX dynamic dependency API to resolve this conflict. When I use the Windows App SDK dynamic dependency API, I find that the Windows App SDK dynamic dependency API is limited to non-packaged applications, and packaged applications will directly fail to call this function. Looking at the source code, we found that this is due to the fact that the WASDK's dynamic dependency API has actively restricted this, and we hope that the Windows App SDK team will remove this restriction and allow the packaged application to be called normally.

---------------------------------------

我的项目共同使用了 WinUI 2 和 WinUI 3，WinUI 2 和 WinUI 3 共同包含 Microsoft.UI.Xaml.dll 依赖库，需要使用 MSIX 动态依赖项 API 来解决这一冲突。当我使用 Windows App SDK 动态依赖项 API 时，发现 Windows App SDK 动态依赖项 API 仅限于非打包应用，打包应用调用该函数会直接失败。查看源代码发现，这是由于 WASDK 的动态依赖项 API 主动对此做出了限制，希望 Windows App SDK 团队能把这一限制去掉，允许打包应用程序正常调用。

---

WindowsAppSDK/dev/DynamicDependency/API/MsixDynamicDependency.cpp

Line 36 in aa9c8b8

RETURN_HR_IF(HRESULT_FROM_WIN32(ERROR_NOT_SUPPORTED), AppModel::Identity::IsPackagedProcess());

#4819

[DrusTheAxe]

As you note this is ByDesign. WinAppSDK's implementation of Dynamic Dependencies depends on more than the Mdd*() APIs e.g. it also relies on the Bootstrapper API and the Microsoft.WinAppSDK.DDLLM.* (aka DDLM) packages being registered for the user. The latter aren't published to Store, and without them the WinAppSDK DynDep design doesn't hold water. Addressing this would require significant Store enhancements or increased complexity to you the packaged app developer (or possibly both).

Or...packaged apps can declare static package dependencies (<PackageDependency...>) in their appxmanifest.xml and voila! Problem solved.

Given the simple manifest option the added costs and friction to make WinAppSDK's Dynamic Dependency API work for packaged apps had too little ROI to justify.

Alternatively, you use the OS Dynamic Dependency API. That has no restrictions on packaged vs unpackaged process -- all can use it.

Does that meet your needs?

[Gaoyifei1011]

As you note this is ByDesign. WinAppSDK's implementation of Dynamic Dependencies depends on more than the Mdd*() APIs e.g. it also relies on the Bootstrapper API and the Microsoft.WinAppSDK.DDLLM.* (aka DDLM) packages being registered for the user. The latter aren't published to Store, and without them the WinAppSDK DynDep design doesn't hold water. Addressing this would require significant Store enhancements or increased complexity to you the packaged app developer (or possibly both).

Or...packaged apps can declare static package dependencies (<PackageDependency...>) in their appxmanifest.xml and voila! Problem solved.

Given the simple manifest option the added costs and friction to make WinAppSDK's Dynamic Dependency API work for packaged apps had too little ROI to justify.

Alternatively, you use the OS Dynamic Dependency API. That has no restrictions on packaged vs unpackaged process -- all can use it.

Does that meet your needs?

Forehead. As you said, dynamic dependencies are introduced for packaged applications precisely because static dependencies don't meet the requirements.
The packaged app consists of two apps, a WinUI 3 desktop app and a UWP app. The Microsoft.UI.Xaml (WinUI 2) for the PackageDependency item declared by the static dependency is in front of the Windows App SDK. UWP can load WinUI 2's Microsoft.UI.Xaml.dll normally, and the WinUI 3 desktop application program should load Microsoft.UI.Xaml.dll of the Windows App SDK, but due to the order of PackageDependency, WinUI 2's is loaded incorrectly Microsoft.UI.Xaml.dll, causing the desktop application to fail to start. Therefore, dynamic dependencies are introduced to forcibly modify the application package diagram of WinUI 3 so that WinUI 3 desktop applications can normally use the Microsoft.UI.Xaml.dll of the Windows App SDK.
To some extent, this may also be a problem with the framework design of WinUI, which does not have different file names for different dlls.

---------------------------------

额。正如您所说的，打包应用正是由于静态依赖项不能满足要求，所以才引入了动态依赖项。
打包的应用里面包含两个应用程序，一个是 WinUI 3 桌面应用程序，另外一个是 UWP 应用程序。静态依赖项声明的 PackageDependency 项的 Microsoft.UI.Xaml（WinUI 2） 位于 Windows App SDK 前面。UWP 能正常加载 WinUI 2 的 Microsoft.UI.Xaml.dll，WinUI 3 桌面应用程序程序本来应该加载的是 Windows App SDK 的 Microsoft.UI.Xaml.dll，由于 PackageDependency 的出现顺序，错误的加载了 WinUI 2 的 Microsoft.UI.Xaml.dll，导致桌面应用程序启动失败。故引入动态依赖项，强行修改 WinUI 3 的应用包图，使 WinUI 3 桌面应用程序能正常使用 Windows App SDK 的 Microsoft.UI.Xaml.dll。
某种程度上来说，这可能也是 WinUI 的框架设计问题吧，没有为不同的 dll 设置不同的文件名称。

---

Static dependencies（静态依赖项）

WinUI 2 Microsoft.UI.Xaml.dll

WinUI 3 Microsoft.UI.Xaml.dll