The best practices for an application packaging environment independent of the packaging tool, has always been a clean virtual machine. The Operating System should be the same as the target with minimal software installed, normally just Microsoft Visual C++ (x64/x86). In the post I’ll share some interesting findings.
To be honest, my approach has always been never repackage, never repackage, okay let’s repackage! That means that I spend a lot of time trying to figure out the proper silent install arguments and repacking is the final exit. Master Packager already wrote a great post on when you should and shouldn’t repackage here. In this example we’re going to use an application called Digital Piper Fitter.
The list below applies to all Operation Systems:
- Vanilla OS with latest Windows Updates
- Microsoft Visual C++ (x64/x86)
- Hypervisor Tool
- Disable Antivirus and Firewall
- Disable Windows Update
- Uninstall UWP Apps – Get example script here
After the list above has been complete the Virtual Machine should be shutdown to create a clean snapshot of the current state.
Windows 7
The industry best practice has always been that the OS should be as similar to the end-user environment as possible. So why are people still packaging on Windows 7? The reason are simple, it’s super clean out of the box without all the noise that comes with Windows 10. I’ve never had problems with MSI or App-V packages created on Windows 7 or Windows Server 2012R2.
157 files and 6 registry entries was captured for our test application.
Windows 10 / 11
Windows 10 / 11 comes with lot’s of built in crap like UWP apps, telemetry services etc. etc.
WOW! 727 files and 182 registry entries was captured for our test application. Needless to say, deploying this MSI as is will make more harm than good. Cleaning up the package will require a PhD and lots of testing. But there is some hope, Master Packager release a new version with better exclusion list together with MSIX support in late January 2022.
Windows Sandbox
Windows Sandbox provides a lightweight desktop environment to safely run applications in isolation. Software installed inside the Windows Sandbox environment remains “sandboxed” and runs separately from the host machine. A sandbox is temporary. When it’s closed, all the software and files and the state are deleted.
162 files and 25 registry entries was captured for our test application. Isn’t that just beautiful? So with the upcoming improved exclusion list, Windows Sandbox will be the recommended Packaging Environment. The only drawback is that there’s nothing in the VM, so I created a PowerShell script that fixes that automatically.
You can download the script from my Github repo. So Windows Sandbox combined with the amazing Run in Sandbox tool from MVP Damien Van Robaeys is a killer combo for anyone working with Application Lifecycle Management. Simply right click my PowerShell script and select Run in Windows Sandbox. And that’s it!
