Software packaging
Invent nothing: four rules AppCloud365 follows when it builds a package
A package that fails silently in deployment costs more than one that is never built. Why we verify hashes, never guess commands, obtain tooling only from official sources and report exit codes unchanged.
There is one kind of error that is particularly expensive in everyday packaging: the package that looks successful. The job says “done”, the deployment says “installed”, and three days later it turns out that the uninstall never worked or the installer was not the one you meant. When we designed AppCloud365, it mattered more to us that this cannot happen than that every application runs through at the push of a button. Four rules came out of that.
Rule 1: No download without a hash
Every manifest in the WinGet catalogue contains the SHA-256 checksum of the installer. AppCloud365 downloads the file on the server, calculates the hash while receiving it and compares it with the manifest. If it does not match, the file is discarded and the job fails with a clear message. The file is never delivered in that case, not even “for inspection”.
On top of that come rules you only miss when they are absent: downloads only over HTTP and HTTPS, no credentials in URLs, no connections to private network ranges, size limits, time limits, and file names coming from the URL or the server are sanitised before they touch the disk.
Rule 2: Commands are not guessed
The second rule sounds trivial and is the hardest: install and uninstall commands come exclusively from manifest data and from what is reliably known about the installer family.
An MSI gets msiexec.exe /i with the silent parameters. The uninstall exists only if a valid GUID ProductCode is present; then it reads msiexec.exe /x "{GUID}" /qn /norestart. Inno Setup and Nullsoft installers get the documented default switches of their framework if the manifest does not name its own. An EXE installer without a known switch gets a command without a switch, explicitly marked as unsafe. And if no uninstall command can be derived, the wizard says so: “Uninstall command could not be determined automatically.” Then you enter one or confirm explicitly that the package has none.
What does not exist: a ProductCode on an EXE installer that silently turns into msiexec /x. That would be an assumption, and assumptions are worth nothing in a deployment script.
Rule 3: Tooling only from official sources
PSAppDeployToolkit and the Microsoft Win32 Content Prep Tool are third-party software. AppCloud365 never downloads them at runtime. A separate bootstrap fetches the current stable version from the official repositories, checks release status, file size, archive content and mandatory files, and stores them outside the web directory. Pre-releases are skipped. If the tooling is missing, the interface shows the affected packaging options as unavailable instead of building a package without a toolkit.
Rule 4: Exit codes are not sugar-coated
The native wrapper without PSADT runs the confirmed command and passes the result on. Exit codes 0, 3010 (restart recommended) and 1641 (restart initiated) count as success. Every other code is reported unchanged as a failure. There is no “unknown means okay”. Without a confirmed uninstall command, Uninstall.ps1 deliberately produces an error with the message that the command could not be determined, so that the deployment reporting shows the gap.
The same principle applies to the build itself: a run that fails produces no package. The first meaningful message from the tool ends up in the job’s error message, not in a log nobody opens.
Why this costs speed and is still faster
These rules mean that AppCloud365 does not package every application fully automatically. A portable program without manifest data only gets the original download; an exotic installer asks for a manual uninstall command. That is intentional. The time it costs is time a packager would have to invest anyway, just earlier and visibly. The time it saves is the night in which two hundred devices report a package that only looked as if it had worked.
All images show the real application with fictitious demo data.