473,396 Members | 1,748 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,396 software developers and data experts.

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

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.

May 10 '06 #1
4 1969
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" <ro*****@pacbell.net> wrote in message
news:eA**************@TK2MSFTNGP04.phx.gbl...
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.

May 10 '06 #2
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.

"VJ" <vi********@yahoo.com> wrote in message
news:ud**************@TK2MSFTNGP04.phx.gbl...
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" <ro*****@pacbell.net> wrote in message
news:eA**************@TK2MSFTNGP04.phx.gbl...
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.


May 10 '06 #3
"Rob R. Ainscough" <ro*****@pacbell.net> wrote in message
news:OF**************@TK2MSFTNGP05.phx.gbl...
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

May 10 '06 #4
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.

"John Vottero" <JV******@mvpsi.com> wrote in message
news:uk**************@TK2MSFTNGP02.phx.gbl...
"Rob R. Ainscough" <ro*****@pacbell.net> wrote in message
news:OF**************@TK2MSFTNGP05.phx.gbl...
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

May 11 '06 #5

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: krisk | last post by:
Could not find ansewr: in ProjectInstaller, RunInstallerAttribute: ..... this.serviceInstaller1.ServiceName = MyServiceName; in the code: public class MyService :...
8
by: D Busby | last post by:
List I've made a .NET windows service in C++, then I added an installer to the solution. I added the 'Project Output' from my .NET service as a package for the installer to install however it does...
7
by: sidd | last post by:
Hi All, i have some doubts on .net windows services.. please see if some one could help me understand this.. 1)is it possible to install a windows service which does not have a installer added...
1
by: BuddyWork | last post by:
Hello, When a particular user (has administrator rights) on a Windows 2000 Server SP4 tries to run any MSI's we get the message mentioned in the subject. If we logon with another user that has...
8
by: vtxr1300 | last post by:
I've followed 2 very similar tutorials on creating a windows service and an installer. But, after successfully compiling it, I try to do the InstallUtil command, but I get a...
6
by: =?Utf-8?B?Qm8gTWNJbHZhaW4=?= | last post by:
I have a installation package which installs ok when setup.exe is used, but if I try to install via msiexec, I get an error "This installation package could not be opened. Verify that the package...
1
by: Dave | last post by:
I have a Console app, a related Service Project and Service Setup / Installer Project. I would like to have the result of running the installer.msi file register the service to run with certain...
8
by: Juhein˝juhein | last post by:
Hello. I have this strange problem when installing autocad lt 2006. Or actually I´m creating an administrative image when I´m trying to deploy the CAD. So the problem is this: First when I...
1
by: =?Utf-8?B?TG9zdEN1Yg==?= | last post by:
I was told (I suspect incorrectly) to increment the Version of my setup project every time I build a new MSI or the MSI won't install. When I do that it tells me to change the ProductCode...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.