Downgrading and unversioned files

[jberg]

Dear Advanced Installer team,

I'm a bit stuck in the following situation:
We have a merge module of a service that is shared between different applications. This service is implemented in .NET Core, and therefore many .dll files are accompanied by a .deps.json file.

In hindsight, every .deps.json file should have been added to the component of its .dll, and made a companion. Unfortunately, we went with the default layout, and all unversioned files are bundled in one component. Its key file is also one of the json files. There are already some MSIs published with this merge module, so we can't change that.

If a user installs an application that contains an older version of this merge module, alongside an already installed and more recent one, the dlls are not downgraded, but the json files are. This is expected according to the file versioning rules, but this also breaks the installation. What I've tried so far:

- Check that the component ID and key file are still the same.
- Give the files an explicit version number. This is only used during installation, so the old one overwrites them.
- Make the files companion of a DLL. The old installer overwrites them, and I suspect this is because the referenced DLL is in another component. (The key file cannot be a companion, so that one will be overwritten no matter what -- but I could work around that.)
- Add a dummy DLL to the component just for the version number, and make them companions of that one. They still get overwritten, and I guess it's because the old installer doesn't know about this dummy DLL.
- Turn on "shared amongst packages". No dice, still end up with the old jsons.


What do you advise?

Thanks!
Jeroen

[Catalin]

Hello Jeroen and welcome to our forums,

If a user installs an application that contains an older version of this merge module, alongside an already installed and more recent one, the dlls are not downgraded, but the json files are. This is expected according to the file versioning rules, but this also breaks the installation.

If you want to always overwrite a file, despite its' version, you can use the "Always overwrite existing file" option --> "File Operations Tab" article.

Always overwrite existing file
If this option is enabled, the file from your package is overwritten and any similar file already present on the target computer. Usually, this can be used when performing a downgrade (install a file older than the one already installed) or for non-versioned files which don't overwrite the existing files.

Hope this helps!

Best regards,
Catalin

[jberg]

Hi Catalin,

Thanks for the welcome, and for your help! Unfortunately, I cannot make any changes to the old, already published installers. Even if I could, downgrading the DLLs themselves is not ideal; if there's a newer application already installed, it might rely on functionality that is not available in older versions of the service.

(Just to summarize: suppose we have an MSI of application A that comes with version 1 of the service, and an MSI of application B that comes with version 2. A is already published, B not yet. Somebody who has B installed might decide to install A later. The desired outcome would be that both A and B use version 2 of the service.)


I probably painted myself into a corner here. If that is indeed the case, I would greatly appreciate your advice on how to proceed.

Just as an example, we could install version 2 in a different directory, add a mechanism to look in both the old and new locations, and start up the newest it can find. Far from ideal, but at least there's a chance we can make it work. But if we do this, is there a better (or at least simpler) alternative than a merge module? All we need basically boils down to, "here's a zipfile, unpack it over there if it's not there yet, or if there's an older version". Perhaps this is easier in MSIX? Or perhaps with a few custom scripts?

[jberg]

Dear support team,

Any news on this? We could really use your help!

[Catalin]

Hello Jeroen,

First of all, please accept my apologies for the delayed reply.

If a user installs an application that contains an older version of this merge module, alongside an already installed and more recent one, the dlls are not downgraded, but the json files are.

downgrading the DLLs themselves is not ideal

Here, I thought that you would like to downgrade the DLL files.

If I understand this correctly, you would like the JSON files to not be downgraded in this case?

Just as an example, we could install version 2 in a different directory, add a mechanism to look in both the old and new locations, and start up the newest it can find. Far from ideal, but at least there's a chance we can make it work. But if we do this, is there a better (or at least simpler) alternative than a merge module? All we need basically boils down to, "here's a zipfile, unpack it over there if it's not there yet, or if there's an older version". Perhaps this is easier in MSIX? Or perhaps with a few custom scripts?

I've tried to think about a solution to this, but unfortunately I am not quite able to, at least without testing.

In order for me to further investigate this, could you please create a sample project that reproduces this issue and forward it to me by e-mail at support at advancedinstaller dot com? Here would be the required files:

- a download link for the older setup

- a download link for the newer setup

- the .AIP file used to build the older setup

- the .AIP file used to build the newer setup

- the merge module

- the .AIP file used to build the merge module

- a test case which can help me in reproducing the problem (e.g. some details about what I should look for)

Best regards,
Catalin

[Catalin]

Hello Jeroen,

As a followup to my last thread:

I've been thinking a little bit more about this scenario.

Most likely, the JSON files are overwritten when installing an older version because they are unversioned - as opposed to the DLL Files.

A suggestion here would be to create a search (in "Searches" page) by the DLL version of your service and then condition the component of your service based on the search. This would require to have access to the older setup project and modify it, though, which you've mentioned you can not really do since it is already deployed to your users.

Other than this, I'm afraid I can not think of any other possible solution.

Best regards,
Catalin

[jberg]

Hi Catalin,

Thanks for your help! Indeed, the issue is with the .deps.json files being unversioned. They are output by the compiler as part of the build process, so it's very important that everything stays as it is.

I wrote earlier that, in hindsight, we should have made them companions of the DLL. However, I just realized that this is not quite what I want either; it could very well be that we change the .NET Core version, but keep some DLLs at the same version. This would change their dependencies, and this needs to stay as it is. So that's not foolproof either. (Yeah, we could manually bump all DLL version numbers to trick the installer, but that introduces new headaches.)

What I want probably does not even fit the Windows Installer model that well, with its concept of versioned and unversioned files. Because the versions of my files are not even important. It's a mixed bag of binaries and other types, but they belong together, and that bundle is what has a version -- so to speak. So if someone installs a newer version, it should end up on their drive exactly like how I packaged it. And if someone tries to install an older version, it should be ignored completely.

Let's say I start writing my merge module from scratch. How could I accomplish this? And would this be easier in, say, MSIX or some other system?

[Catalin]

Hello Jeroen,

Yes, your scenario is quite "complicated" so to say.

What I want probably does not even fit the Windows Installer model that well, with its concept of versioned and unversioned files. Because the versions of my files are not even important. It's a mixed bag of binaries and other types, but they belong together, and that bundle is what has a version -- so to speak. So if someone installs a newer version, it should end up on their drive exactly like how I packaged it. And if someone tries to install an older version, it should be ignored completely.

You are indeed right, what you want does not really fit the Windows Installer model. However, please note that this is still possible.

For instance:

So if someone installs a newer version, it should end up on their drive exactly like how I packaged it.

This would be possible through the "Always overwrite existing file" option. Let's say we have version 1.0.1 of a DLL file. If in an upgrade version of the package we have version 1.0.0 of the same DLL, by default Windows Installer will remove the older version during the upgrade process (when the older package is uninstalled), but will not install the "newer" version, because its' version is lower than the one uninstalled.

However, if the "Always overwrite existing file" option is used, the version 1.0.0 of the DLL file will be installed on the machine, despite its' version being lower.

And if someone tries to install an older version, it should be ignored completely.

Here, please note that this is by default the behavior of Windows Installer. If a user has the "2.0.0" version of your setup installed on the machine and then it tries to install the "1.0.0" version, Windows Installer should throw the following warning:

warning.png (96.67 KiB) Viewed 4645 times

If the user clicks "Ok", the installation process will then be terminated.

Let's say I start writing my merge module from scratch. How could I accomplish this? And would this be easier in, say, MSIX or some other system?

As I have mentioned above, if you want your files to always be overwritten by the newer installation, I'd advise using the "Always overwrite existing file" option - this is pretty much the only way to do this. Basically, when this option is used, the file's version is set to the maximum value possible (65.535 if I'm not mistaken), therefore it will always be overwritten.

Regarding your second request, as I have explained above this is pretty much the Windows Installer default behavior, therefore here nothing special should be done.

Regarding this:

And would this be easier in, say, MSIX or some other system?

An update is possible with the MSIX technology. However, I can not really say whether this would be simpler than the MSI approach.

MSIX is a somehow "new" technology which is still developing, therefore it has a lot of "limitations".

If you would like to have a look into the MSIX technology, we have some nice articles that can get you started, e.g.:

MSIX Tutorial: A comprehensive 24-chapter guide

Hope this helps!

Best regards,
Catalin

[jberg]

Hi Catalin,

You're right, it would be easy if it's just an application being upgraded. However, I'm dealing with a merge module here that is shared between different application installers. And those applications can be installed side-by-side. (Turning the service into an application of its own would solve this, but it was my understanding that hiding an MSI within another MSI was difficult to say the least, so we went with the merge module approach.)

[Catalin]

Hello Jeroen,

You are indeed right. Even if it were to create the merge module from scratch, the fact that it is shared between multiple setups that can be installed side-by-side may cause us some troubles.

Turning the service into an application of its own would solve this, but it was my understanding that hiding an MSI within another MSI was difficult to say the least

Could you please give me some more details about what you mean by this (i.e. "hiding an MSI within another MSI")?

Normally, if it were to create a setup separately for your service, you could just add it as a prerequisite in your main package. This can be done really easily.

Best regards,
Catalin

[jberg]

I was thinking of a concurrent (or "nested") install:
https://docs.microsoft.com/en-gb/window ... dfrom=MSDN
Adding it as a prerequisite would indeed avoid this, and this covers our use case nicely.

Thanks for your help!

[Catalin]

Hello Jeroen,

You are always welcome!

There is no need to use that approach, as it even mentions in that article that the feature is deprecated - especially when we can achieve that much easier.

Best regards,
Catalin