Software packaging
WinGet provides the installer, PSAppDeployToolkit the behaviour
The WinGet catalogue knows more than 14,000 applications with installer, hash and silent switches. What it lacks for enterprise deployment, the PSAppDeployToolkit adds. Why AppCloud365 combines the two.
Anyone who packages software for Windows knows the two hours a “small update” costs: find the installer, check the version, guess the silent switch, try it on a test machine, forget the uninstall, add the uninstall later. Microsoft’s WinGet catalogue has done part of this work for everybody at once. It just does not know how software should be deployed in your organisation. That is exactly where the PSAppDeployToolkit comes in, and exactly why we combine the two.
What the catalogue can do
The repository microsoft/winget-pkgs is a collection of manifests. For every application and every version they list the installers with URL, type, architecture, scope and SHA-256 hash, often also ProductCode, UpgradeCode and the silent switches. As of August 2026 that is around 14,600 applications, 165,000 versions and 324,000 installers.
AppCloud365 mirrors this catalogue into a local database. A separate sync process clones the repository and afterwards only processes the changes since the last run. Removed packages are marked inactive rather than deleted, so the history is preserved and no ghost packages appear.
What the catalogue lacks
A manifest describes an installer. It does not describe what should happen when the application is running during installation, how errors are logged, which exit codes count as success, or how the installation behaves towards signed-in users. For a developer installing a tool on their own machine, none of that matters. For a rollout to two hundred devices it is the difference between a quiet night and a loud one.
The PSAppDeployToolkit, PSADT for short, has been the standard for defining exactly this behaviour for years: close processes, inform users, write logs, handle return codes, uninstall and repair in the same script. Version 4 ships a template with clearly marked places for the install and uninstall calls.
The combination
AppCloud365 takes the verified installer from the catalogue and places it in the official PSADT v4 template. The session variables for vendor, name, version and architecture are set, the install and uninstall calls are inserted at the designated markers. The result is a PSADT package like the one you would build by hand, minus the two hours.
The commands come from the manifest. An MSI gets msiexec.exe /i "file.msi" /qn /norestart and, if a valid ProductCode exists, the matching uninstall call with /x. An Inno Setup or Nullsoft installer gets the documented silent switch of its framework if the manifest does not name one. An EXE installer without a known switch is honestly marked as unsafe instead of being given a guessed parameter.
And if you do not want PSADT?
Some environments deliberately do not use the toolkit. For them AppCloud365 builds a lightweight native wrapper of Install.ps1 and Uninstall.ps1 that runs the confirmed command and passes the exit codes 0, 3010 and 1641 through as success. Both variants can be wrapped with the Microsoft Win32 Content Prep Tool as .intunewin, ready for Intune. If you prefer Configuration Manager or a classic distribution, take the ZIP.
What this means day to day
“Update 7-Zip” becomes: search the application, choose the version, click a packaging option, read the summary, build, download. The knowledge that used to live in one packager’s head now lives in the manifest and the template. And when the manifest does not know something, the wizard says so instead of hiding it.
The catalogue provides the installer. The toolkit provides the behaviour. AppCloud365 brings the two together without inventing anything on top.
All images show the real application with fictitious demo data.