Musings of an Application Packager

Sometimes, you'll come across COM registration keys that look like this: But what are they exactly?   If you look at the registry keys created, you'll notice how it doesn't look like a normal COM DLL being registered (although its similar).  Normally, you'd have the InprocServer pointing to the DLL that's being registered, but in this case there's additional registry values being written that you wouldn't normally see that relate to the registration of a COM DLL.   That's why you won't see these entries being placed into the Windows Installer advertising tables (ProgId, Class, etc), and that these entries appear in the Registry table.   Using regasm.exe to register the assembly as a COM DLL with the /codebase switch and exported the results into a .REG file to get the following: REGEDIT4 [HKEY_CLASSES_ROOT\IPSMapControl.UserControl] @="IPSMapAx.IPSMapControl" [HKEY_CLASSES_ROOT\IPSMapControl.UserContr

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

I recently came across a problem with a VBScript which simply navigates to two intranet URLs (opening one in each tab), but coming up with the following error: The VBScript source code (comments omitted) simply contains the following: navOpenInBackgroundTab = &h1000 set oIE = CreateObject("InternetExplorer.Application") oIE.Navigate "http://host1:8080/app" oIE.Navigate " https://exchangeserver/owa ", navOpenInBackgroundTab oIE.Visible = true  Line 23 refers to the last line of the code, but why are we getting an error when this script previously worked fine under Windows XP? This MSDN blog ( http://blogs.msdn.com/b/ieinternals/archive/2011/08/03/internet-explorer-automation-protected-mode-lcie-default-integrity-level-medium.aspx ) has the answer, but  if you're struggling to understand some of the concepts let's review: The key points to understand are:  - The Internet Explorer Frame Manager always runs