IsFramework flag for Microsoft.WindowsAppSDK.Main and Microsoft.WindowsAppSDK.DDLM packages

[jwht]

I want to create an MSIX with a dependency on the above packages.
I have tried using the <PackageDependency> element in my package manifest, but that only works for dependencies that are "marked as a framework package" (https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-packagedependency).
Microsoft.WindowsAppSDK.Main and Microsoft.WindowsAppSDK.DDLM are not marked as framework packages; Get-AppPackage reports IsFramework: False.
This is not the case for the Microsoft.WindowsAppSDK package, which is marked as a framework and can be specified as a <PackageDependency> successfully.

Anyone know whether these packages are intentionally not marked as frameworks, and if so, it there another way to specify them as dependencies?

[andrewleader]

@DrusTheAxe can you help with this?

[jwht]

Actually it's okay - we have realised we don't need to distribute those non-framework packages, as they are required for non-packaged apps only. So they should never need to be dependencies of an MSIX package. Thanks anyway.

[DrusTheAxe]

Only a main package can declare a dependency on a framework package (<PackageDependency>), and you can only declare a <PackageDependency> to refer to a framework package, as noted here:

PackageDependency...

Declares a dependency on another package that is marked as a framework package.

MSIX supports multiple package types. Windows App SDK uses a framework package, supplemented by main packages to help accomplish things we can't with just the framework package.

Anyone know whether these packages are intentionally not marked as frameworks

No

it there another way to specify them as dependencies?

No

don't need to distribute those non-framework packages, as they are required for non-packaged apps only

Yes and no. The DDLM packages are only needed by unpackaged apps. The Main (and Singleton) package are needed by all apps (packaged and unpackaged). This is a problem for Store-deployed packaged apps, as an MSIX package can't declare a dependency on a main package. We're working on a solution; you can find more information in the Windows App SDK Deployment API Design #1253.

P.S. When I say "main package" I'm referring to 'a package with PackageType=Main". OTOH when I say "Main package" (or more often, "WARmain") I'm referring specifically to the Microsoft.WindowsAppSDK.Main package.

[jwht]

Thanks for your reply, @DrusTheAxe. It seems we may require Microsoft.WindowsAppSDK.Main after all, so we will be interested to learn how we can install this.

I still don't understand why this package isn't a framework; that would mean we could add it as a <PackageDependency> in our app manifest, and hence install it automatically via our .appinstaller file.

But given that it isn't, it sounds like we'll be able to call an API function to install it at runtime instead; is that correct?
Is there a roadmap for when this function might be available? And will it be callable from a non-elevated app?

[MarkIngramUK]

(As a side note, it would be useful to document what the package Microsoft.WindowsAppSDK.Main is for. There doesn't seem to be any documentation relating to it, so it's not immediately obvious if we need that dependency in our final package.)

[DrusTheAxe]

we may require Microsoft.WindowsAppSDK.Main after all, so we will be interested to learn how we can install this.

If you're MS Store distributed, you'll be interested in Windows App SDK Deployment API Design #1253. The Store will install the framework package (if not already present) with your main package, and then your app calls the API to install the rest (if necessary).

If you're not MS Store distributed then the easiest way is to use the installer. Simply running the exe installs the WindowsAppSDK packages (if not already present) in a non-interactive way (simile to vs_redist_x64.exe or dx9setup.exe). Alternatively you can install the MSIX packages yourself using the standard MSIX deployment tech (PackageManager APIs like AddPackageByUriAsync, Powershell cmdlets, etc).

@zaryaf got links? (I know we've got docs but I never recall where they live. I promise to remember this time. Pinky swear :-)

why this package isn't a framework; that would mean we could add it as a <PackageDependency> in our app manifest

That would be cool. Unfortunately <PackageDependency> only expresses a Framework dependency. MSIX doesn't support a way to declare a dependency on a main package.

install it automatically via our .appinstaller file.

Similarly, .appinstaller files lets you declare Framework (and Optional) package dependencies but not dependencies on other Main packages.

P.S. To round out the set of package types... Resource packages can be included in a Main package's Bundle package and retrieved by Windows if/when necessary.

But given that it isn't, it sounds like we'll be able to call an API function to install it at runtime instead; is that correct?

Yep! See Windows App SDK Deployment API Design #1253 for details.

Is there a roadmap for when this function might be available?

It's under active development and we're targeting 1.0, though I see the roadmap doesn't mention Deployment. @zaryaf @andrewleader that's something we should correct...

And will it be callable from a non-elevated app?

Yes! The API uses PackageManager APIs to install the packages so elevation is NOT required. As long as the you're running as MediumIL (aka FullTrust) or you're in an AppContainer and have the packageManagement restricted capability you're good to go.

AppContainer processes without the packageManagement capability lack the power to install packages so the upcoming deployment API's won't work for them. Our options are rather limited here (we built too good a sandbox :P) but we're still investigating.

it would be useful to document what the package Microsoft.WindowsAppSDK.Main is for. There doesn't seem to be any documentation relating to it, so it's not immediately obvious if we need that dependency in our final package

Great suggestion. I know folks are busy working to expand the documentation for 1.0 but I don't know the full details. But as they say you don't have to know everything, just everyone ;-) Passing word to @zaryaf who's more involved in the upcoming Deployment documentation. Thanks for the feedback.