Skip to content

Conversation

@neo42JBR
Copy link

The implementation shown provides the c# backend to work with Appx packages.

A demo implementation was added to Get-ADTApplication to preview its capabilities.
The function implementation is limited to provisioned packages, as this reflects "system installed" packages equivalent to how ARP entries are queried.

The backend exposes methods to work with both provisioned and installed packages, either per user or any.
All methods are purely static and work solely on an identifier basis.
I avoided adding requirements for the Windows SDK to handle appx management to reduce external dependencies.
Information about packages is extracted from the registry and the manifest files they point to.

Filtering for family names is supported, however currently there is no property to expose this property in InstalledApplication.

@neo42JBR
Copy link
Author

Technically the ability to read the manifest information from an installer would be easily implemented as the bundle can be read as zip and the manifest file could be extracted.
However importing System.IO.Compression collides with .NET 8.

@DanGough DanGough deleted the branch PSAppDeployToolkit:main December 11, 2025 23:10
@DanGough DanGough closed this Dec 11, 2025
@DanGough
Copy link
Contributor

Sorry, Next was a temporary branch, this PR was not closed intentionally. @mjr4077au will be in touch!

@mjr4077au mjr4077au reopened this Dec 11, 2025
@mjr4077au mjr4077au changed the base branch from next to main December 11, 2025 23:19
@neo42JBR
Copy link
Author

After discussion with @mjr4077au this will require #1925.
Most of the code will also be ported to PS where applicable

@neo42JBR
Copy link
Author

The commit I just pushed already implements #1925, without full wiring in the toolkit yet.
The structure of inheritance is the following:

                       | -> InstalledArpApplication -> InstalledMsiApplication
InstalledApplication - |
                       | -> InstalledAppxApplication

I also dropped everything except the GetPackageFamilyName function from c# to powershell.

Nearly all logic is now packed into the new Get-ADTPackageManifest function that can read package info from an installer (like we do with MSI) or any other valid manifest file.

Sorry @mjr4077au, I had to force push because most of the changes you applied were not relevant anymore. The ones that still were I tried to apply where applicable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants