IMPORTANT: Wrong order of nodes in XML .config file after upgrade

[Zsolt Kollarits]

Hi Daniel,

Could you please have a look at the files I sent you and review this whole ticket including all of our problems with your feature sometime in the near future? Just let me know if you need anything else from my side. Due to our release cycle we have to decide in the beginning of this week whether your feature can handle our XML files or we have to revert all of our changes. Obviously reverting our changes would mean that all of the work we invested into this topic - changes of our commercial project, time invested into testing, sample projects, sample files - is just wasted.

Best regards,
Zsolt

[Antarctica]

For the corner cases where order is important, you may have to create a small custom action. That's what we had to do to fix some ordering issues we had with XML files in AI.

[Daniel]

Hello Zsolt,

I've finished reviewing once more your complex XML updates scenario, but unfortunately there is no chance you can fulfill all of your corner case requirements using our "XML Updates" feature. There are too many corner case scenarios which our predefined functionality cannot cover due to the complex and volatile format of your XML file.

Unfortunately you are trying to make sure that certain XML blocks (some of them which are very hard or even impossible to uniquely identify after being changed by the user) be preserved using the user changes, other blocks with the same structure be completely re-written by erasing the user changes and other blocks (same structure) be partially overwritten and partially keep the user applied changes. I wish that our "XML Updates" support be that powerful and configurable so that cover all of your requirements, but simply it isn't. Thank you for your understanding.

Here are my replies to your last outstanding queries:

<!-- For AI: Here should always be only 1 form subnode, if the customer modified the value for example from WinLogin
to VALUE_TO_KEEP_19, then only VALUE_TO_KEEP_19 should stay here. You will see that the upgrade will keep
VALUE_TO_KEEP_19, but it also puts back the original <form>, so it´s going to be 2 form subnodes here which is not correct. -->

To achieve this you should edit the attributes of your "forms" element like this:

image 1.jpg (73.16 KiB) Viewed 7326 times

<!-- For AI: There are quite a few location nodes below. We don´t want the user to change them, the values should be always
reverted based on the latest XML coming from the new product. You will see that these location nodes will be kept and
the original nodes (which are missing now) will be re-added by the upgrade, you will find them at the very bottom of the XML file.

Expected behavior: path values should be simply reverted and no new location sections should be added to the end of the file. -->

Unfortunately this is not possible because we cannot uniquely identify your "location" nodes. If the only item (the attribute value) we could uniquely identify the element is changed by the user, then there is no way for us to detect this element precisely.

<!-- For AI: Some mimeMap nodes were uncommented by the user, they should be kept after the
upgrade procedure. This section is something we would always like to keep. -->

The uncommented "mimeMap" elements are kept after the XML update, but if you want to skip in this case the installation of the XML comment (whose content is the commented "mimeMap" elements) then I'm afraid this is not possible either. We really do not have any option nor workaround solution in our XML Updates feature to skip the installation of an XML comment (whose content is a block of XML elements) when the same block of XMl elements is found in the content of target file at install time.

Thank you once again for your understanding.

All the best,
Daniel

[Zsolt Kollarits]

Hello Daniel,

Finally we decided to implement our own mechnanism with inline PowerShell custom actions so our plan is to make the following screnario working:

1. After an install or update procedure is finished, a custom action writes the hash of our config file to the registry. We know the last installed config file´s hash.

2. If an installation happens (before file removal, right in the beginning), a custom action compares the new (coming from the latest EXE) config file´s hash with the one in the registry. If they are different, the powershell custom action creates a copy (backup) of the file and modifies a property or a registry key in order to store the name of the config file for which a backup was created.

3. On the last dialog of the installer (ExitDlg) the user should see a new text contains the value of the property or the registry key. The user will be modified that a backup was created.

The individual custom actions are working. It means the installer writes out the files hashes properly as well as it creates the correct backup files based on the hashes in the registry. The last remaining problem is that I´m not able to show this information for the customer on the ExitDlg. First I tried to save the name of the backup files into a global property (created on Install Parameters tab) by using AI_SetMsiProperty and then load the value of that property into a new Text control of ExitDlg, but it seems the property is getting a value too late.

In the second round I also tried to store the name of the backup file in the registry before file removal and then read that registry value right before ExitDlg, but it did not work either. Somehow the order of custom actions is wrong.

I´m attaching a sample project that installs 3 config files. The goal is that the next update pack creates a backup of the config file you modified in the previous version and the name of that config is printed out on ExitDlg. So please create a few update packs by increasing the product version number and install them. Please always modify the content of at least one config file before you perform an installation.

Sorry for the long email, but it´s important that you understand what the custom actions should do. Could you please help us finding the correct order of our custom actions?

Best regards,
Zsolt

[Daniel]

Hello Zsolt,

Please give me some time to review your current implementation and I'll get back to you as soon as I have a reply.

Thank you for your patience.

All the best,
Daniel

[Zsolt Kollarits]

Hi Daniel,

Just for your info I managed to figure out a working order of our custom actions, now everything is working as expected if we install MAJOR update packs over each other.
But in case of MINOR updates, none of our config files are being replaced, although I use the "Always overwrite existing file" option for those files.

Could you please have a look at this problem?

Best regards,
Zsolt

[Daniel]

Hello Zsolt,

In what regards your MINOR upgrades installation scenario, the web.config files are not overwritten because you have enabled the "Do not register this component with Windows Installer" option for their component. In this case the component files won't be installed (overwritten) during a patch or repair operation.

A minor upgrade installation acts exactly like a patch installation, therefore your updates.config files won't be installed during a minor upgrade because of their components have the "Do not register this component with Windows Installer" option set.

To avoid this issue, please proceed like this:

1. go to "Files and Folders" page and select a "web.config" file
2. right click on it and choose "Go to component" option
3. for the selected component in "Organization" page uncheck the "Do not register this component with Windows Installer" option
4. repeat the above steps for all "web.config" files

In what regards the working order of your custom actions, please note that this happens because of the Windows Installer design. Windows Installer doesn't pass the installer property value from "Install Execution Stage" to "Dialogs Stage". Therefore and property value set during "Install Execution Stage" will be lost when the installation process moves to "Finish Dialogs Stage". I can confirm you that moving your custom action to "Finish Dialogs Stage" is the correct solution for this issue.

Hope this helped.

All the best,
Daniel

[Zsolt Kollarits]

Hi Daniel,

Thanks for your proposal, but the only problem with this is that we checked "Do not register this component with Windows Installer" option on purpose. Basically we found this solution under a different Advanced Installer ticket, where it was explicitly written that "Do not register..." checkbox must be checked.

Reason: We don´t want to register our .config files because - as you may have seen - we have a custom action that removes or renames the file on uninstallation. So we would like to handle the uninstallation of that file in all the cases, otherwise our whole - compare old and new file and uninstall or rename depending on the comparision - mechanism is broken.

But still our mechanism is not working if the new .config file is not installed by a MINOR update pack. It means we have to find a solution which allow as to handle the .config files ("Do not register..." is ON) and works in case of MINORs as well. Unfortunately the scenario what we have to achieve is quite complex :S

Best regards,
Zsolt

[Daniel]

Hello Zsolt,

In this case I would recommend you NOT to use the minor upgrade option for your setup packages. I'm afraid I'm not aware of any workaround solution for your case.

All the best,
Daniel

[Zsolt Kollarits]

Hi Daniel,

We used to release our update packs as MINORs, only the yearly release comes as a MAJOR. Just because of a "bug" we don't really want to blow up our release policy. Just to summarize the facts of this ticket:

1. Originally we wanted to preserve some nodes of our config (XML) files on product upgrade by Advanced Installer's Edit XML function. We've spent several weeks by creating a sample project for you and trying to configure your feature for our needs. We listed all the issues but some of them could not be solved, that's why we had to accept we can't use your feature for our needs. For more info see the previous posts of this thread.

2. At this point we decided to implement our own solution within our Advanced Installer project by using custom actions. After some research we found a ticket which was more or less the same:
viewtopic.php?t=9936
Based on the new info, we modified our .aip and added some new searches, a new property, 3 new custom actions. Working out and testing this solution also took quite a long time. We also create a sample project for it just in case we need to send it to you.

3. Apparently one more issue we found: the solution is not yet working if we install MINORs over each other. Unfortunately this is something we can't fix on our own, we needed to ask your help for it. To make it easier for you, we've also sent over the sample project. Could you please try to make that sample working even with MINOR update packs? (Repro steps are also written in earlier posts.) We will use MINORs in the future as well as we have to add this new feature to our .aip because our customers are asking for it. Moreover we already invested too much time in it. It's also fine for us if we uncheck the "Do not register..." checkbox for our xml files, but in that case please propose us a different order or condition of our custom actions. If that relevant checkbox is unchecked, the custom actions are not doing their job for some reason, I think that's because of their order or position. We were strugging quite a lot with their position, finally we made them working for MAJORs, please help us fixing it for MINORs too.

Best regards,
Zsolt

[Daniel]

Hello Zsolt,

I've retested your scenario having the "Do not register this component with Windows Installer" option unchecked and after each update install (major and minor upgrade) the .config files were successfully overwritten. Can you please make sure you are using the same component GUID for the .config files through all the setup project version? Each .config file should have the same component GUID through all the project versions.

If this is still of no help, can you please give us more details (maybe a step by step test case we can follow) so we can replicate the issue you are currently facing with?

All the best,
Daniel

[Zsolt Kollarits]

Hi Daniel,

This ticket is getting more and more complicated so let me summarize it, because it´d be good to have it solved. We´re going to have our big release next month, until then we have to solve it somehow.

In one of your previous letters you wrote me this:
"In what regards your MINOR upgrades installation scenario, the web.config files are not overwritten because you have enabled the "Do not register this component with Windows Installer" option for their component"

In my last letter I just basically emphasized that we CANNOT DISABLE "Do not register this component with Windows Installer" option and that´s why MINOR upgrades are not working fine for us.

The reason why we cannot disable it? It´s also explained in my last letter. A summary of it:
1) Originally we wanted to preserve some nodes of our config (XML) files on product upgrade by Advanced Installer's Edit XML function but it was unsuccessful. See earlier posts of this thread.
2) Then we tried to implement our own solution (with custom actions) based on
viewtopic.php?t=9936
This solution requires "Do not register this component with Windows Installer" to be ENABLED - that´s why we cannot disable it. In my previous letters I also wrote down that we performed some tests and tried to disable it, but then the solution under the link is not working.
3) We ask you help to figure out a solution where "Do not register this component with Windows Installer" is ENABLED, but still MINORs update packs are working fine. Why do I ask you for some ideas? We wasted a lot of time on step 1) when we tried to solve it with your XML file feature - which should theoretically be capable of doing what we want -, we followed your instructions, helped you with sample .aip-s, but found no solution. Then we wasted even more time on step 2), when we had to implement it with custom actions. Finally we managed to make it working, only MINORs are not working. Unfortunately your previous recommendation of "you NOT to use the minor upgrade option" is not acceptable for us, we are massively using MINORs in our release cycles.

Best regards,
Zsolt

[Daniel]

Hello Zsolt,

I really am not able to find any solution including the "Do not register this component with Windows Installer" option ENABLED.

The only solution I can think of is to keep DISABLED the "Do not register this component with Windows Installer" option for your components and use a custom action on uninstall which check the hash of your config files and if they were altered by the user then it should backup and restore them on the uninstall process.

It is not a simple and smooth solution, but without keeping the "Do not register this component with Windows Installer" DISABLED I see no way so that your product be minor upgrade compatible further on. Thank you for your understanding.

All the best,
Daniel

[Zsolt Kollarits]

Hi Daniel,

Just to inform you, after another round of investigation apparently we managed to fix it by doing the following modification in our sample .aip project:
"Maintenance" checkbox has to be enabled in the Execution Stage Condion section of our new custom actions, otherwise the custom actions are not executed while a MINOR update pack is installed. At least this is what we could see from our tests. For now the custom actions seem to do their job, we´ll get back to you in case any other problem pops up.

Thanks,
Zsolt

[Daniel]

Thank you for your follow up on this Zsolt.

All the best,
Daniel