COM Register/Installer "RemovePreviousVersions = True"

2482
4
10-10-2011 05:20 AM
JamesCrandall
MVP Frequent Contributor
I can't seem to shake these COM installer/registration issues I've had over the last 6mo's or so, and this one is a little new/different this time.  As the title suggests, I cannot seem to fully succeed at the whole process to properly install AND register my COM components that are packaged into a Setup project and deployed as the .msi to each user to install on their respective computers.

ArcGIS v10 COM Component .dll/.tlb
Implments ICommand/IToolBar (includes an IToolBarDef class too)

First, let me say that an initial run of this built .msi works great!  As long as there are no existing references to the .dll's being deployed.  That is, if the install is done on a workstation that has not had the COM component installed, then it runs exactly as desired.

So, with that said I am now attempting to re-deploy this COM component again because it contains some updates....

In the Setup Project/Assembly (by clicking directly on the project in the Solution Explorer), I have set RemovePreviousVersions = True and changed the Version as well (this automatically changes the ProductCode after clicking "Yes").  I then re-build the setup project.

(note: I can go thru all of the other items like my InvokeESRIRegAsm.dll and the registration code I have in the ICommand/IToolBarDef classes, but again, the first go/run of this deployment works so I don't think there is anything wrong with these).

(note2: I did set the Register property of the main .dll to vsdraDoNotRegister, but the .tbl is set to vsdrfCOM)

Results:

1.  If I simply copy the new .msi over to the target computer and run it, no errors and everything seems to install as desired.  But the original COM Component (a Toolbar) remains the same and does not contain the updates.  So, basically it doesn't seem to have registered.

2.  If, after step 1. above I do nothing and re-step thru the process of adding the .tlb by way of Customize--> AddFromFile... then again, nothing seemingly goes wrong but the toolbar doesn't register again.

3.  If prior to running the new .msi I go thru the process of manually unregistering the COM component by the Categories.exe, then removing the insalled component by way of the ControlPanel--> Add/Remove programs, then re-run the .msi ----- everything works as expected.

In summary --- I can accomplish what I need by simply performing step #3 above.  However, I do not have admin priv's and the install process is done throughout the organization by IT Department technicians and there are simply too many things to do for them to efficiently run the installations.  I need a way to simply provide them with the new .msi, have them run it, the new COM component is up and running. 

Any insight, input or comments are greatly appreciated.

James
0 Kudos
4 Replies
JamesCrandall
MVP Frequent Contributor
After a bit more research, I have applied a fix that seems to work.  Well, it DOES work to fix my problem however I am not completely certain of any extra side affects that it may cause --- as far as I can tell, there are none, but that doesn't mean this will apply to your situation.  So please peform your own analysis before taking the same approach.

Ok, so from what I can tell/understand, the .msi Installer is ignoring the main .dll when the re-installation is performed.  Why it cannot determine if it need to be reinstalled I am not sure, but this seems to be the behavior.

The solution is to set the REINSTALLMODE=amus property of the .msi --- you have to do this with an application called "Orca", which is downloaded from Microsoft.  The amus property stands for these settings and applies them to the files in the .msi package:

a - Force all files to be reinstalled, regardless of version.
m - Rewrite all registry keys that go to HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT.
u - Rewrite all registry keys that go to HKEY_CURRENT_USER or HKEY_USERS.
s - Reinstall shortcuts and icons.

*This is why I say you will need to do your own analysis of this to determine if this would be a good solution for you because your scenario may contain shared files/folders that could be negatively affected by the amus property. 

Anyway -- that is my current solution.
0 Kudos
NeilClemmons
Regular Contributor III
I'm also experiencing some strange issues lately and one of the things that I found was that when Visual Studio creates the .msi file it is putting the step to uninstall the previous version at the end of the install sequence.  So, in other words, it is installing the application then removing the previous version which results in files being missing.  Using Orca I have to change the install sequence every time I rebuild the installer.
0 Kudos
JamesCrandall
MVP Frequent Contributor
I'm also experiencing some strange issues lately and one of the things that I found was that when Visual Studio creates the .msi file it is putting the step to uninstall the previous version at the end of the install sequence.  So, in other words, it is installing the application then removing the previous version which results in files being missing.  Using Orca I have to change the install sequence every time I rebuild the installer.


I find it to be a maddening experience.

As an aside, and if you are still watching this thread Neil....

What to do when someone runs an Uninstall prior to unregistering the COM component?

As I mentioned in my OP, the EIT technicians are running these installation processes for the GIS department and they don't necessarily know about these COM things.  I have an instance where someone ran in uninstall (via Add/Remove Programs), but now I cannot unregister the COM components with the Categories.exe Component Category Manager application.  It lets me go thru the steps, but it never actually removes the reference from the list!

Thanks for the input.
0 Kudos
NeilClemmons
Regular Contributor III
Uninstalling the application from the Control Panel should unregister the COM classes.  The deployment project should have a custom action on both Install and Uninstall to run the component registration code in each COM class.  Sometimes this custom action breaks if your project output has changed so give it a look to make sure it's there and valid.
0 Kudos