MSI Installer will not work with .NET 1.1 Windows Services upgraded to .NET 2.0

[Rob R. Ainscough]

The task is brain dead simple - Uninstall prior Windows Service and Install
newer version of Windows Service

Background:
1. My Windows Service written in .NET 1.1 and deployed via MSI (Windows
Installer)
2. My Windows Service is upgraded to .NET 2.0 with deployment project using
MSI (Windows Installer)

Upgrade code is the same from the .NET 1.1 version to the .NET 2.0 version
(Product code has changed, per MSDN spec)

The .NET 2.0 deployment will NOT "RemovePreviousInstall" no matter what
approach I use. Works fine across .NET 2.0 app versions, but not with .NET
1.1 to .NET 2.0.

My only conceptual solution to this problem is:

Code a .NET 1.1 App to force MSIEXEC /x {product code} uninstall (as I can
make the assumption .NET 1.1 is installed) and then have the .NET 1.1 App
shell the Setup.exe for my .NET 2.0 deployment MSI (which will install .NET
2.0 as needed).

I find it hard to believe this is the ONLY way to accomplish this? I've
read Phil Wilson book (Windows Installer) and from that it seems I have no
other options. I've tried in vain to use Installer class and and/or custom
actions to trigger the uninstall of my prior windows service, but that
results in "Only one instance of installer can be run at a time...."

If someone knows the person or dev team responsible for MSI work, please
share -- I would like to ask them some questions -- I've spent the past 3
days trying to do what should be a VERY simple task, only to be hit with
road block after road block and limitations (specifically imposed) of
Windows Installer.

Rob.

P.S. The fact that I and Brandon are getting ZERO responses (on multiple
news groups/forums) I would have to assume many other developers have opt'd
out from using MSI at all for what I dare suggest are the same reasons I'm
bumped into.

 

[VJ]

You are correct Rob... we had to do the same.. Run to packages.. one to
remove previous 1.1 installation and then add the 2.0 version. Frustrating..
but liveable.

I am very much interested in learning a alternate option...

VJ

 

[Rob R. Ainscough]

Livable perhaps, but some documentation to indicate such limitations could
have saved me 3 wasted days and long hours trying to convince myself that
this can be done the MS way.

I got my own installer to work in a couple of hours of coding and testing.
The more I read about MSI, the more likely I'm going to avoid it.

Mention MSI in various tech forums and you can hear a pin drop -- nobody
either wants to talk about it or has gone thru the same frustration and
either went with a 3rd party product and/or coded their own solutions (as I
did). Seeing as 3rd party products such as InstallShield are ridiculously
priced I can see why coding one's own solution is a far better option --
which ironically is exactly what MS don't want developers.

 

[John Vottero]

Livable perhaps, but some documentation to indicate such limitations could
have saved me 3 wasted days and long hours trying to convince myself that
this can be done the MS way.

I got my own installer to work in a couple of hours of coding and testing.
The more I read about MSI, the more likely I'm going to avoid it.

Mention MSI in various tech forums and you can hear a pin drop -- nobody
either wants to talk about it or has gone thru the same frustration and
either went with a 3rd party product and/or coded their own solutions (as
I did). Seeing as 3rd party products such as InstallShield are
ridiculously priced I can see why coding one's own solution is a far
better option -- which ironically is exactly what MS don't want
developers.

I think this is a .NET Framework issue, not an MSI problem. It's also not
just a V1.1 to V2.0 problem, it's always a problem. This is one of the
reasons why we stopped using the classes in the
System.Configuration.Install.Installer hierarchy. When you use an Installer
class marked with the RunInstaller attribute, Visual Studio generates an MSI
that calls InstallUtilLib.dll as a custom action. InstallUtilLib loads your
V1 assembly and calls the Uninstall methods. The MSI then continues and
when it gets to installing V2 of your product, MSI again calls
InstallUtilLib.dll which loads your assembly so that it can call the Install
method but, the assembly is already mapped (from the previous Uninstall) so,
your V2 install winds up calling your V1 code.

I don't really know if that bug is MSI's problem or the .NET Framework's
problem. There are some MSI people that think the whole .NET Framework
Installer hierarchy is evil and should be avoided. I don't know enough
about MSI to fully understand the problem. Apparently the Installer class
doesn't do reference counting properly (which is a completely different
issue).

Anyway, one workaround we found for this problem is to break your Installer
classes into two separate classes in two separate assemblies. One is for
installing and one is for uninstalling. When I was dealing with this
problem, it was strictly V1.1 of the Framework so that workaround might not
work when you're also dealing with different versions of the .NET Framework.

We wound up eliminating all Installer classes and we use WiX to build our
MSIs. We're really happy with WiX but, I still hope the issues with
Installer classes are addressed.

John Vottero

 

[Rob R. Ainscough]

Thank you for the link to Wix -- I'll look into it.

I assume with such an obvious problem, MS didn't actually expect anyone to
upgrade their apps from .NET 1.1 to .NET 2.0. I think what has happen here
is that MS were listening to IT people too much and were consumed by the
"rollback" feature such that the obvious was ignored.

These leaves me with a very uneasy feeling about .NET 2.0 click once
deployments -- as in will they work when .NET 3.0 is out and we upgrade
those apps -- my guess is I'll be screwed again and will have to come up
with some "other" solution.

Rob.