What identifies an installer?

NickDay · Postby **NickDay** » Tue Mar 24, 2015 3:39 pm

Hi,
We have a pretty urgent problem; I'd appreciate a response today if possible please as we need to release an installer tomorrow:

We have an existing product installer (IA12), which has been run on customer PCs.

I wish to make a new version of the installer, and avoid the user seeing the modify/repair/remove dialog (yes, I know I could hide it in other ways).
Basically I want the new installer to run and not recognise that it has already been run on the PC. It should just do a first-time install, not force uninstallation first.

To achieve this, I changed the Product Code to a new GUID and built the installer.

If I run this new installer on a PC where the previous version has been run, into the same location, it appears to runs and install as if it's a first-time install, just what we want.
However, if I look at the files it installed, they are unchanged -- they're the files which are installed by the old installer; it has not overwritten the existing files.

I think what's happening is that the system is recognising that this installer has been run before, and is installing using the old cached setup source (both versions of the installer have 'Always cache setup sources' checked).

I expect to be able to overcome this by changing more than just the Product Code GUID; for instance maybe the product name must be changed too.
Is anyone able to tell me please, which settings must be changed before an installer is treated as completely different?

Thank you,
Nick

PS I have many times duplicated an existing installer project, changed the Product Code GUID and other settings, and had it treated as a new installer. So the question is, which other settings made the difference?

Postby **FrancescoT** » Wed Mar 25, 2015 11:12 am

Dear Nick,

an installed application is idenfied by a unique; PRODUCTCODE and UPGRADECODE.

If you change the PRODUCTCODE and UPGRADECODE, you also need to use a unique Target Folder for the application you are going to install.
This can be easily achieved by using the setup VERSION with the application target folder.

Example; "C:\Program Files (x86)\<COMPANY>\<TITLE>\<VERSION>" or "C:\Program Files (x86)\<COMPANY>\<TITLE + VERSION>".

In addition, if other components have to be shared across the different application versions, you must handle them in order to not interfere with any installed version of your application or with any version of your application you are going to install/remove.

Hope this helps you.

NickDay · Postby **NickDay** » Wed Mar 25, 2015 12:57 pm

Thank you Francesco.
My initial thought is that this won't help, as we need to install into the same target folder, on top of the previous installation.
I need to think about it and do some experiments, and am grateful for your reply.
We have had other occasions where we have run a new installer into a folder which was the target of a previous installation, with no problems. So I suspect there's more to it.
Best regards,
Nick

Postby **FrancescoT** » Wed Mar 25, 2015 1:36 pm

...Otherwise, the other alternative is with using a Transform Instance.
The "Transform Instance" command allows new installations of an already installed product on the same system.

Search for "Transform Instance" in the IA documentation and have a look at the "Multiple Instances" sample.

Personally I am not a "Transform Instance" fanatic, but maybe it could be right for you.

Regards

NickDay · Postby **NickDay** » Tue Apr 07, 2015 8:08 am

Thank you Francesco,

Apologies, this is rather a long reply as I'm trying to make sure to explain our situation clearly.

We do use 'transform instance', but only in a specific situation -- allowing several parallel installations branded to different OEMs. Thanks for suggesting it.
Does transform instance require that we install into a new unique target folder, too, or can we use it to install into the same location as a previous install?

Requiring that the installation is made into a unique folder path also means that the user must not browse to the location of their existing installation (maybe after deleting the files) and installing into that. I can't see how we could prevent that apart from using showing a warning telling them not to do so.

For now we have worked around the problem by reverting the installer project to the previous Product Code GUID and version number.
I expected that this would let me install the earlier release, then run the new installer and get the maintenance dialog, allowing us to uninstall.
But instead, I am finding that the new installation is just installing as a fresh installation (which is what we wanted all along, though I can't explain why this is happening), and it is installing the correct versions of the files, rather than incorrect, older, versions from the cache.

It seems that our cache problems should be overcome if we turned off 'Alway cache setup sources', which is currently checked in our main installer project. This was done in order to avoid the user being prompted to locate the original setup sources, so I am loath to turn off cacheing. If you can suggest a way that we can turn off cacheing, AND avoid the 'original setup sources' prompt, that would be ideal.

Going back to your original reply,
>If you change the PRODUCTCODE and UPGRADECODE, you also need to use a unique Target Folder for the application you are going to install.
etc.

Our installer installs files in other locations than the target directory -- for instance under the Program Files folder and Appdata. How do those stand re. the need to install into a unique folder (to avoid future installations sourcing these files from the cache)? It seems that if a file exists in the cache AND in the installer, it uses the cached file. If it exists in the installer, but not the cache, it throws a 'The system cannot find the path specified' error. Neither of these are what we want, which is to simply install the files which are contained in the installer.

In particular, our main installer is used to install our product for several different OEMs, who require different customisation of product name, default installation location, etc.
How we currently achieve this is to install a text file ('Settings.txt'), right near the very start of the installer MSIcode, into a location under Appdata. This file is built into the installer, is different for each OEM build, and contains the badging text we need to apply to the installer and the files it installs. The MSIcode script reads the Settings.txt file it just installed, and badges itself accordingly.

After changing the Product Code to a new value, I found that the installer would sometimes error when attempting to install Settings.txt, 'The system cannot find the path specified', even though it is certainly built in to the installer. The only way found it was to let the installation complete, then run it again and uninstall, then install it a third time. Our installer is around a gigabyte, when uncompressed, so this is very time consuming.

I think what was happening was that it was trying to install Settings.txt from the cache, and it was not present (as the original installation was made when we installed Settings.txt in a different location). I expected it to install 'from' the installer itself, not from the cache.

Well, that's the background. My question is: can you suggest a different way to get the 'Settings.txt' badging information into the installer, which would avoid this problem with the cache? One way would be just to have it sitting as a text file alongside the installer executable, but we'd prefer to avoid that and have it built into the installer as this is a single file.

Thanks again for your assistance.

Postby **FrancescoT** » Tue Apr 07, 2015 1:19 pm

Dear Nick,

The "Transform Instance" command allows new installations of an already installed product on the same system, so this means that there are no requirements to install into a unique target folder. Otherwise, what would have to be the advantage to use such capabilities?

For what concerns the rest it may be interesting to know how your project is intended to be deployed. I'll try to be more specific.
You said that your need is to have a different package in order to target different OEM build, at this purpose it could useful to know how the package to install is effectively organized. For example, do you have a core component in your installer which is identical with all your different OEM installations and another one that differs depending on the OEM build?

If this is the case, why don't you consider the possibility to deploy the final OEM build as a customized wrapper that internally uses and installs your core component (... which could be an independent and unique package ... as generally occurs with installed application runtimes)?

Obviously I am only supposing the above scenario, due the fact that I don't know what your package requires or has to install.

Let me know and if you prefer to not share sensible information, you may contact me at: support@installaware.com .

Regards