Windows 7 - MSI uninstall not executing Installer class tagged with [RunInstal

Asked By Nathan Evans

14-Dec-09 10:04 AM

We are developing a MSI installer solution (based on VDPROJ, unfortunately)
that will install an instance of our server application. The installer has
all been designed to support the concept of installing multiple instances.
This means we have written a small utility that takes a 'stub' MSI and then
outputs a configured MSI with a unique Product Code, Product Name etc amongst
other things. The Product Code is updated in both the Property table and
Summary Information stream.

Everything seems to work fine on the install step. Our two test instances,
AcmeCorp and ZurgCorp, are installed side-by-side just fine. Their Windows
Services are all registered and function as expected.

However, we have encountered a very strange issue when it comes to
uninstalling one of these instances. It does not matter which instance we
uninstall first. But which ever one we choose, the uninstall will proceed
very quickly - but so quickly that it actually misses out calling our .NET
Installer subclass (tagged with RunInstaller and being called by the
CustomAction).

The uninstall will be 'successful' and the MSI will be gone from Add/Remove
Programs list. But the Windows Service remains behind because the MSI
uninstaller never run our assembly to remove it!

Now if we go ahead and uninstall the second instance as well, this one will
uninstall just fine including the Windows Service.

So what on earth is going on here?

It smells to me of some form of reference counting. But where? We've
followed the book on this when it comes to making sure the Product Code's are
different. Maybe there is something we are missing to do with Component Id's?

Thanks.

14-Dec-09 11:17 AM

I have now run the uninstall process with full debug tracing enabled and it
does indeed appear to be related to the Component Id's.

I can see on the uninstall where the Windows Service is not removed that the
debug trace many entries like this: "Disallowing uninstallation of component:
{long guid here} since another client exists"

So it appears the MSI, despite having a different Product Code and even
Upgrade Code, is actually conflicting with the MSI of the other instance
through the Component Id's.

I wonder what the solution is here, other than regenerating the Component
Id's for each instance?

14-Dec-09 01:22 PM

Visual Studio's internal component guid generation uses something relating
to the location where it is being installed so it tries to share properly,
and it is doing the right thing as far as the files are concerned because
they are being shared, and you are not in fact side by side at all.  Sharing
is not about product codes, it is component guids. So the service file is in
the same location in both products, right? Like many of the other files?
Changing component guids will not help because there will be no ref counting at
all, and the files will be removed if just one of the products is
uninstalled, and I do not think that is what you want to happen.

Why is not the current behavior correct? You have two products installed that
share a bunch of files and a service. When you uninstall one product the
sharing works properly, files stay behind, and the service stays behind
because it is used by the other product. When you uninstall that other
product as well everything cleans up ok.
--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972

14-Dec-09 02:32 PM

Phil,

I do not dispute the legitimacy of this behaviour of MSI.

It just is not "fitting" for what we need it to do. We have multiple
customers on a single machine (SaaS basically) and none of these installs
must share any resources. Yes it seems wrong to have lots of duplicate files
on the hard disk but for us this is not a problem. Our server software
amounts to about 30MB... And having each customer's install completely
isolated from each other enables us to perhaps apply a patch to an individual
customer without affecting others.

I have come up with a solution now which basically involves rewritting the
ComponentId values on the Component table.

Thank you for your response, and I do agree with what you are thinking...
that our solution is probably a bit of a "hack".