In the last post we created a basic installer to deploy our product files and source into a user-specified location. In this post we’ll look at the Registry-related activities that need to happen from our installer.
One of the files we added to the install project was the RegDL executable. We’re going to add some custom actions which use this executable to create/remove our demand-loading Registry entries on install/uninstall.
The advantage of this approach is that we don’t need to duplicate information in an installation script that’s already stored in our .NET assemblies: RegDL queries an assembly programmatically for its command metadata and uses that to create accurate demand-loading information in the Registry. I should say that I haven’t fully tested this executable on different Operating Systems, so please bear that in mind. That said, the source code is available on the linked post, in case someone finds an issue and wants to debug it.
Let’s head across to the Custom Actions view:
From here we can add an action in the appropriate place – in this case under “Install”:
At which point we browse through the “target machine” path to our RegDL executable:
Which takes a few clicks:
Until we can finally select it:
This creates a custom action with default options, which we can edit via the properties window. We need to set the InstallerClass property to False and pass this argument to the tool: “[TARGETDIR]ADNPlugin-BatchPublish.dll”:
We can then do the same for uninstall (and rollback, just to be safe). In this case we want to add the “/unregister” option to the Arguments string:
In theory it should also be possible to create separate Custom Actions for “Just Me” (with a Condition property of ALLUSERS=“”) or “For Everyone” (with a Condition property of ALLUSERS=“1”). I did start to do so, but had some trouble with RegDL being called in “all users” mode: it seems to have trouble accessing the CurrentUser section of the Registry when called under these circumstances, and as AutoCAD only installs the “CurVer” property per-user, it would take some additional work to extend RegDL to work properly under these circumstances.
Rather than make this update now, we’re going to support only “Just Me” installation for this tool (and we’ll see how to remove the “For Everyone” radio button from the installer UI in the next post).
So we can see our three custom actions (the “uninstall” one also repeated for “rollback”, although that may well be redundant):
If we look at the contents of the Registry using regedit.exe, we should see our Registry entries have been created under the most recently run AutoCAD version on your system:
It’s important to note that the RegDL tool currently only installs to the most recently run AutoCAD version: if you need something more flexible than this, then more work will be needed to extend the tool.
That takes care of our AutoCAD-related registration (i.e. creation of the Registry entries needed to enable demand-loading for our application).
The next Registry-related task we need to take care of is to register one of the 3rd party modules we use (ComUtilities.dll, a component of the CsWbEx2 utility) for COM. If we select it in the Solution Explorer we can edit its properties in the properties window:
Changing the Register property to vsdrfCOM will allow it to be registered for COM. Be warned that if you’re installing/uninstalling this on your development machine (always a bad idea, but that’s also what I’m doing, for what it’s worth :-), then you will probably see regular build errors after uninstall, as the ComUtilities.dll file gets unregistered for COM. And if you reopen the Visual Studio solution when this file is not registered, you may well see it disappear from the install project.
(A quick tip: I have a shortcut to regsvr32.exe on my desktop, and whenever I need to register a COM DLL manually I simply drag it from Explorer (yes, standard Windows Explorer) onto the desktop shortcut, which registers the DLL for COM. Easy! :-)]
I did try setting SharedLegacyFile to True, hoping that the additional reference counting would cause the DLL not to be unregistered on uninstall, but that didn’t end up making a difference.
So now the application should actually be functional: without loading the application manually into AutoCAD, we have the Registry entries in place allowing the application to be loaded automatically when the BP command is entered, and the COM DLL needed to show our custom browser is also registered and available.
The final Registry-related change we’re going to make is a launch condition to only install the application on AutoCAD 2011 or higher. Let’s take a look at our project’s Launch Conditions:
The default conditions contain one for the appropriate version of the .NET Framework to be installed:
To check for the right AutoCAD version, we’re going to check HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\CurVer (CurVer being a property under the AutoCAD root key). To do that we’re going to add a Registry search by right-clicking the Search Target Machine node:
We’re going to put the contents of the CurVer property (“R17.1”, “R18.0”, “R18.1”, etc.) from SOFTWARE\Autodesk\AutoCAD under the vsdrrHKCU root into a custom variable called ACADVER:
We can then go and add our actual launch condition:
We link this back to our ACADVER property by setting our Condition property to ACADVER>=“R18.1” with an appropriate message for when the launch condition is not met:
This will cause the following message to be displayed when the installer is run on a system on which AutoCAD 2011 or higher has not been run most recently (this is planning for the future: you may not want such an open-ended condition, in practice, but I’m trusting the relatively limited functionality of this plugin to continue to work in future releases).
That’s it for this second part in the series, focusing on “all things Registry”. In the next (and hopefully final :-) part, we’ll take a look at adjusting the installer’s user interface, both from a cosmetic and a functional perspective.
