I guess this topic is pretty redundant, well kind of. I’m sure some applications will require shims for future Windows OS releases. But anyways! I created a post back in May, when I was focused yet again on another Packaging effort being driven by a migration to Windows 7. Now, in that post I walked through how to create shims (you view that HERE ) but never really went into how to deploy the shim so it can be used with your application. For this post, I’m going to assume the application is not virtual. Shims do work with all the good Application Virtualization solutions and the shims can be deployed for these quite easily (some through scripting within the tool or just using your favorite deployment tool) but let’s focus on MSI\MST or Scripted installs.
Scripted Installs
First, let’s touch on the scripted solution. Well this is prety easy this can just be a simple bat file as the install and uninstall of a shim can be executed via the commandline such as:
sdbinst.exe -q <Path>\ApplicationNameFix.sdb
Unfortunately, each shim which is installed creates it’s own entry under Add\Remove Programs and as it’s not an MSI, you can’t just open and tweak these ARP settings yourself. As you may imagine, if you have many shim for applications, your Add Remove Programs will get cluttered. You can resolve this by setting a DWORD registry for the sdb install under the Uninstall registry hive. You could do this using whatever scripting means you which, for example with vbscript:
On Error Resume Next
Set oshell=CreateObject(“WScript.Shell”)
oshell.RegWrite “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{c73a11d3-6e4f-4436-9f09-1392d41161ce}.sdb\SystemComponent”,1,”REG_DWORD”
The GUID used for this registry can be found by installing the Shim on a machine and doing a search under the Uninstall hive.
The Uninstall can be executed:
sdbinst.exe -u <Path>\ApplicationNameFix.sdb
MSI\MST
Open your package with your favorite Editing tool. For my example, I’m using Flexera Installshield because that’s how I roll.
Add your .sdb file to either a new component or an existing component. I suggest having the component Destination set to INSTALLDIR, as you can this variable with the custom actions we’re about to create.
You’ll want to create a ‘NEW EXE using the Path referencing a directory’ Custom Action. This is my own preference, if you’d like, you could add the sdb to the package into the Binary table. I prefer to Install the sdb with the application and then execute the install towards the end of the install. I do this because I like to be able to run a WMI query on all .sdb files. In honesty, I haven’t done that in a few years. The number of .sdb’s in environments I’ve worked in are pretty minimal.
The Working Directory will be set to the location of the sdbinst.exe which is part of the OS. You can see we are using a command very similar to the one shown under the scripting section, only we are using the INSTALLDIR variable as suggested previously. Set In-Script Execution to ‘Deferred Execution in System Context’ to ensure this action is completed in System Context (Administrator privleges) Finally under Install Exec Sequence, you should pick something far down the drop down list e.g. After Publish Product, Expand the Install Exec Sequence and enter the text Not Installed this ensure this action will only run on install.
You will also need to create an Uninstall custom action, for this custom action you’ll use the -u switch. Also you’ll want to change the Install Exec Sequence condition to REMOVE~=”ALL” This ensure this action, yip, you guessed it, will only run on uninstall of the package.
Finally of course you will want to set your registry key to hide the ARP setting. You can do this simply through the registry table or if you want you could just execute it as a vbscript custom action, your call. And that should be it!
