InstallAware

Hi,

using IA 15 I want to create a setup that determines the path of a prior installation without removing it and installs the newer version (different revision code) at the same, maybe customized, path.
The setup must not check for web updates.

How do I do that?

Dear User,

You could retrive the installation path from registry ...

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{PRODUCTID}

Anyway, I am not quite sure to follow what you are going to do.

Regards

FrancescoT wrote:Anyway, I am not quite sure to follow what you are going to do.

Hi Francesco,
sorry for the delay, I was out of office for a week.

I'd like a setup that recognizes a prior installation and does nothing more than exchanging a few files.
Normally one would create a patch for that but caching was not activated and for this version we need another way because we can't expect our customers to follow the procedure of selecting the path to the original sources (it is no product for IT-affine people).

Therefore I created a setup based on the original one, eliminated all files not to change and changed the RevisionCode.
The older setup wrote the installation path to the registry for other purposes. So not uninstalling the prior install, reading that path, setting it as target path and installing the new files should do it I thought.
It doesn't. The setup tells me it copied the files, messageboxes tell me the expected values but the files are not overwritten.

Are other setups doing this (not only those created with InstallAware) custom implementations?
Another thing: Creating a patch gives a result that is almost as big as the original setup (~750 MG instead of the expected 2 MB). Is this because of the integrated .NET framework version?
Is there a way to avoid this?

EDIT: The log says the product was new configured. Does that mean the setup was in maintenance mode? It does not show the maintenance screen.

Regards
Anja

Dear Anja,

how did you create your new setup project?
Are you using NATIVE ENGINE?

Another thing: Creating a patch gives a result that is almost as big as the original setup (~750 MG instead of the expected 2 MB). Is this because of the integrated .NET framework version? Is there a way to avoid this?

I suppose you didn't follow the steps required to create a patch properly and anyway, pre-requisites (as NET Runtimes) are not included with the patch build.

I may suggest you to have a look at the following link (includes a sample project).
http://www.installaware.com/forum/viewtopic.php?f=2&t=9343

Regards

Hello Francesco,

FrancescoT wrote:how did you create your new setup project?

I used the same project (the old one is under source control) and eliminated all dialogs I do not need.
Changed the RevisionCode.
Pointed the source to a location containing only the files to be changed.

Changed the MSI.
The setup looks up the old installation path and sets the target path to that location.

Messageboxes tell me the setup does each step as planned. But it does not make changes to the system. Files are not copied, new values are not written to the registry, file deletion inserted for test purposes are not executed.
The log tells me in it's last section the application was new configured by windows installer.
When I leave that non working project as is and just change the product code everything works as expected and the log tells me the application was successfully installed.

Are you using NATIVE ENGINE?

No.
I used it for test purposes and it had the effect that the above mentioned file deletion was executed but no files were installed.


So: Why does the setup not do any system changes and the log only speak of new configuration?

Regards
Anja

Dear Anja,

first of all, honestly I don't understand why you are using this approach to run your update.

You said;
"Normally one would create a patch for that but caching was not activated and for this version we need another way because we can't expect our customers to follow the procedure of selecting the path to the original sources (it is no product for IT-affine people)."

Why don't you deploy a standard FULL update to your product? In this way you can also fix the "cashed setup sources" problem with the existing installations.

Anyway to return back to your issue, it not clear to me the approach you used. You said to have used the same project as base for the new one, but for what I understand (maybe I am wrong), it seems to me that you changed your PRODUCTCODE or altered the default MSI code functionality.

It seems that your new package doesn't detected that a previous application is already installed otherwise, it should FIRST un-install it and for what I understand this doesn't happen.

am I wrong?

Regards

FrancescoT wrote:first of all, honestly I don't understand why you are using this approach to run your update.

You said;
"Normally one would create a patch for that but caching was not activated and for this version we need another way because we can't expect our customers to follow the procedure of selecting the path to the original sources (it is no product for IT-affine people)."
Why don't you deploy a standard FULL update to your product? In this way you can also fix the "cashed setup sources" problem with the existing installations.

Because as usual in the forefront no-one wanted it. And now "a solution is needed".
A full update is the fallback and the way for future versions to avoid things like this.

it seems to me that you changed your PRODUCTCODE or altered the default MSI code functionality.

It seems that your new package doesn't detected that a previous application is already installed otherwise, it should FIRST un-install it and for what I understand this doesn't happen.

am I wrong?

You are right. I removed the part of uninstallation because I wanted to deploy only the changed files and leave the rest as is. Basically the functionality of a patch that is no path.

In the meantime I introduced NativeEngine and corresponding variables to force overwriting which seems to solve the problem (?)

Trying to reproduce the success I couldn't restart the first setup. It found a previous installed version but could not deinstall it because it had no sources. Productcode and upgradecode of that version were not found in the registry.
With ProcessMonitor (sysinternals) I found that the setup was looking in the registry at HKCR\Installer\Products\{guid}, I removed that key and the setup was able to start. That guid does not match product-, update- or revisioncode. What is it and how is it generated?

Regards
Anja

Dear Anja,

The first approach you used is not correct and it can even compromise the already installed application.
You can't distribute a package in this way, it can't work.

I suggest you to create a totally new project from scratch using the "Blank" template.
In this way a completely blank project will be created (it does not include any pre-defined dialog sequence or any pre-defined script code)

Then in main script, enable the NATIVE ENGINE as first and then define all the specific tasks that you require (Just the commands required - don't use Apply Install). In this way you will create a package that simply executes a sequence of commands on the target machine.

Anyway, I may suggest you to proceed with releasing a standard full update of your product ... at your earliest convenience.

Regards