WASDK PackageVolume is missing APIs related to FindPackageXXX

[Gaoyifei1011]

Describe the bug

WASDK PackageVolume is missing APIs related to FindPackageXXX

Steps to reproduce the bug

See description

Expected behavior

See description

Screenshots

See description

NuGet package version

Windows App SDK 2.0 Experimental 4: 2.0.0-experimental4

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 24H2 LTSC (26100, June Update)

IDE

Visual Studio 2022

Additional context

No response

[Gaoyifei1011]

@DrusTheAxe

[DrusTheAxe]

Not missing. Intentionally not tackled - yet.

Known item on the long-term desired roadmap. One reason it wasn't first out the gate is Find* returns a Package and we'd like to to have a Microsoft.Windows.ApplicationModel.Package offering the same gaggle of quality-of-life, feature enhancements and so on as e.g. WinAppSDK's PackageDeploymentManager and ApplicationData offer over their Windows.* counterparts. But W.AM.Package is big (relatively speaking) and other priorities were more urgent, so Find*() and Package and friends aren't available. Yet.

For a taste of the direction see M.AM.Package.idl.

Another enhancement over the OS Package is the latter is a snapshot of (most) properties when the object is constructed. The upside is it's stable - nothing so fun as a 'live' object's data changing in the middle of use. The downside is perf - you pay for it even if you need only a subset. Fractional and deferred data resolution is another feature you get hints of in M.AM.Package.idl. I have ideas for additional improvements (perf and functional).

Package has some related types we'll need to address - PackageId, PackageStatus, AppListEntry, AppInfo, AppDisplayInfo and so forth. Package is the likely forerunner here, for both its value/ROI and foundational nature (hard to do most of the others w/o Package).

Another is the Find* APIs themselves. The current PackageManager.Find*() are somewhat inconsistent and asymetric. This shouldn't be a surprise, given PackageManager was one of the first WinRT APIs created and it's been under regular organic evolution the past ~15yrs. WinRT API design practices have evolved over the years in many good ways, but backwards compatibility can make more expansive PackageManager enhancements difficult to deliver. PackageDeploymentManager intentionally offers no Find*() to leave the field open for when we're ready to add them, without having to compromise best-practices.

If Find*(), Package and friends interest you please leave your feedback here. What would you like to see? What pain points have you found with the current APIs? What do you wish were more functional, more performant, more convenient to use, or other goals or reasons? Let us know.

[Gaoyifei1011]

Not missing. Intentionally not tackled - yet.

Known item on the long-term desired roadmap. One reason it wasn't first out the gate is Find* returns a Package and we'd like to to have a Microsoft.Windows.ApplicationModel.Package offering the same gaggle of quality-of-life, feature enhancements and so on as e.g. WinAppSDK's PackageDeploymentManager and ApplicationData offer over their Windows.* counterparts. But W.AM.Package is big (relatively speaking) and other priorities were more urgent, so Find*() and Package and friends aren't available. Yet.

For a taste of the direction see M.AM.Package.idl.

Another enhancement over the OS Package is the latter is a snapshot of (most) properties when the object is constructed. The upside is it's stable - nothing so fun as a 'live' object's data changing in the middle of use. The downside is perf - you pay for it even if you need only a subset. Fractional and deferred data resolution is another feature you get hints of in M.AM.Package.idl. I have ideas for additional improvements (perf and functional).

Package has some related types we'll need to address - PackageId, PackageStatus, AppListEntry, AppInfo, AppDisplayInfo and so forth. Package is the likely forerunner here, for both its value/ROI and foundational nature (hard to do most of the others w/o Package).

Another is the Find* APIs themselves. The current PackageManager.Find*() are somewhat inconsistent and asymetric. This shouldn't be a surprise, given PackageManager was one of the first WinRT APIs created and it's been under regular organic evolution the past ~15yrs. WinRT API design practices have evolved over the years in many good ways, but backwards compatibility can make more expansive PackageManager enhancements difficult to deliver. PackageDeploymentManager intentionally offers no Find*() to leave the field open for when we're ready to add them, without having to compromise best-practices.

If Find*(), Package and friends interest you please leave your feedback here. What would you like to see? What pain points have you found with the current APIs? What do you wish were more functional, more performant, more convenient to use, or other goals or reasons? Let us know.

This is my app, and I want to implement an app moving feature, similar to how Windows allows you to set the display. This requires finding the PackageVolume where the app is located and the remaining PackageVolume on the device, so the PackageVolume.FindPackageForUser API is used.

[DrusTheAxe]

This requires finding the PackageVolume where the app is located

I don't see why. PackageManager.MovePackageToVolumeAsync takes 3 parameters:

• packageFullName -- the package to move
• deploymentOptions -- specify DeploymentOptions.None
• targetVolume -- where you want to move to

Move in WinAppSDK would be nice but I don't see its gap as a showstopper. The Windows (OS) APIs are still available. Perhaps not as nice as the WinAppSDK equivalents :-) but still quite functional.

Why do you think you need the PackageVolume where the app is located?

And if you do for some reason I'm not seeing, why are the current Windows.* (OS) APIs not sufficient?