Using Installer Classes and the Step from 1.1 to 2.0

microsoft.public.dotnet.framework

8 Apr 2006 10:28 PM

JMS

I've a MSI setup based on .NET 1.1 (VC#.NET 2003) running for some years now.
The setup includes an installer class. Due to some strange feature inside the
MSI architecture I had to rename the installer assembly each time it changed
(or else in the case of an auto-uninstall the MSI core loades the old
installer assembly, uninstalls and never loads the new one for the following
installation because it thinks it's already in). So when goting to VC# 2005 I
renamed the assembly again. The first setup breaks and reports that the (new)
installer assembly has a wrong file format.

After some analysis I think that is what happens: MSI uses .NET 1.1 to
uninstall. Since the setup does a auto-uninstall / install in one sequence it
then tries to load the .NET 2.0 assembly without restarting the run-time.
Actually this can't work!

Currently the only way I see is to force the users to do a manual uninstall
before the setup. In fact I could remove the 'uninstall previous version'
from the setup project but when the MSI further evolves I will have to
reactivate the flag for best user experience. So in fact this helps only for
those who update to the very first .NET 2.0 version from some older .NET 1.1
version and not users upgrading somewhen in the future. Another way was to
change the product code which as I think will generate even more problems
because the application is installed twice - which is not an option for this
special application.

So is there any idea how this problem can be solved? As far as it understand
the way MSI (seems to) works using .NET based installer classes is a very bad
idea. Is this some problem of MSI or .NET? Personally I would put it on the
MSI which actually should recycle the installation executable just before
installing.

Any hint could be very helpful!

Thanks

Jochen