Repost: Windows service installer

[DM]

I have used VS.Net 2003 to develop a Windows service and a deployment
project to install the service. The service and the installer work fine.

When I modify the service to include some new code in the "AfterInstall"
event of the ProjectInstaller and create a new installer (having set
RemovePreviousVersions = True, changed the Version, ProductCode and
PackageCode properties) the code does not get executed when I install the
new service. Everything else works fine and the new service is successfully
installed and works.

However if I remove the previous version of the service first and install
the new version (rather than letting the installer upgrade the version) the
new code in the "AfterInstall" event gets executed.

How can I get the new code in the "AfterInstall" event to be executed when
the installer upgrade the service?

 

[Sijin Joseph]

Make sure that the UpgradeCode's for both versions are different and that
the ProductCode's are the same.

 

[Guest]

I modified the version number, kept the Product Code and Package Code the
same and modified the Upgrade Code. When I try to install the new version
Windows Installer gives the following error "Another version of this product
is already installed. Installation of this version cannot continue .........".

 

[Sijin Joseph]

Check out this KB article
http://support.microsoft.com/default.aspx?scid=kb;EN-US;830613

 

[Felix Wang]

Hello DM,

Thanks for posting. If we would like to take advantage of the
"RemovePreviousVersions" feature, we must keep the UpgradeCode the same and
increase the product version.

Based on my past experience, the behavior you observe may be related to
some duplicate component code in the 2 MSIs. As a result, the condition for
the custom action may evaluate to false under some circumstances. I would
suggest that we try creating a new Setup Project from scratch for the
updated version of the product, instead of modifying the existing one. Note
that we must keep the UpgradeCode the same for the two Setup Projects and
it would be best if we install the new version of the product to a
different folder.

Does this help?

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Guest]

Hi Felix

I've tried what you suggest and got a different error. When
"RemovePreviousVersions" = "True" I get "System.IO.FileLoadException: Strong
name validation failed for assembly 'tErrorLogMonitor.exe'".

When "RemovePreviousVersions" = "False" both the old and the new versions
are installed.

Dave

 

[Felix Wang]

Hello Dave,

Is it possible that I have a look at the MSIs directly? I just need a
simplest sample that can reproduce the problem. You may add the files to a
zip and attach the zip file here.

I will do some tests on my side.

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Felix Wang]

Hello Dave,

Is there any update on this issue? Is it possible that you create a
reproducible sample for this problem for our further investigation?

Please feel free to post here if there is anything I can help.

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Guest]

Hi Felix

I've put together a very simple sample but it does not reproduce the
"System.IO.FileLoadException" error. So I need to go back and look at my
original code to determine what is different between the projects.

I do have 1 further question though - creating a new setup project for each
release seams a little over thr top. Is it not possible to just change some
properties of the original setup project rather than create a new project?

Thanks

Dave

 

[Felix Wang]

Hello Dave,

Thanks for you update. The intention of building new setup projects is to
ensure that we do not have duplicate component IDs. Duplicate component IDs
may cause confusion to setup projects regarding the condition for custom
actions if we have multiple version of them. I would check whether this
helps to fix the problem or not at the first point.

Another option here is to use some VBScript to automate the task to modify
the MSI output after we build the setup project. However, this can become
quite complex if the setup project is also complex:

About the Automation Interface
http://msdn.microsoft.com/library/?url=/library/en-us/msi/setup/about_the_au
tomation_interface.asp?frame=true

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.