Musings of an Application Packager

One of the fundamental problems inherent in all packaging tools which use snapshotting to produce an MSI package, e.g. Wise Package Studio, MSI Studio Pro, AdminStudio, etc, is its inability to associate registry entries with their respective components.  The result is packages where COM registration data that hasn't been moved to their respective advertising tables (ProgId, Class, TypeLib, etc), and may leave behind several (hundreds) entries in the "Catch-All" component. This problem is further compounded when common run-time files (such as MsComctl.ocx, ComDlg32.ocx, etc) are replaced with merge modules, which leave behind several orphaned COM registration data in the Registry table - thus leaving no longer having the original file to correctly reference. I feel that this is something that these package authoring vendors need to address, especially with major vendors like Flexera, who's Repackager utility has largely been unchanged for several versi

Might be useful to check a manifest has taken effect: By default applications without manifests on Windows 8 (and 7) will run in the Operating System context for Windows Vista http://msdn.microsoft.com/en-us/library/aa374191(v=vs.85).aspx You can use Task Manager to see the context by adding the column "Operating System Context", and also "UAC virtualization" to determine if a 32-bit process has UAC virtualisation enabled.  Note that 64-bit processes cannot be UAC virtualised. For 32-bit processes, by default, UAC virtualisation will be on. As soon as a manifest is added with requestedExecutionLevel set then UAC virtualisation for that process is disabled. http://msdn.microsoft.com/en-us/library/windows/desktop/bb756929.aspx <requestedExecutionLevel level="asInvoker|highestAvailable|requireAdministrator" uiAccess="true|false"/> Some other templates and utilities relating to manifests courtesy of Darwin Sanoy