Modifying the feature list of a patched product is not possible

[Zsolt Kollarits]

Hi Advanced Installer Support Team,

Could you please tell me whether adding a new feature to a patched product - by using the Modify button at Programs & Features - is possible or not? Many of your customers are asking the same and complaining about it, unfortunately I haven't found a proper answer anywhere.

For example the following incident describes the exact same problem we have:
http://www.advancedinstaller.com/forums ... =2&t=26885
As a final anwer your colleague mihai.petcu tells that "Modify seems to work after patching".

He also refers on a different thread in one of his letters:
http://www.advancedinstaller.com/forums ... 308#p53451
In this thread he tells the opposite of his previous words, namely "At this point your clients have version 1.0.1 installed which means they cannot use the 1.0.0 package to perform a "Modify" maintenance operation."

My undestanding is that both incidents try to solve the same problem.

Our scenario is quite a real-life scenario and requires a solution:
1. Customer installs 1.0.0 major version of our product.
2. For some reason we decide to add a small extension to version 1.0.0 (e.g we missed out something), so immediately after the release of 1.0.0 customers get 1.0.1 as a patch.
3. Now all of our customers are having 1.0.1 in Programs & Features.
4. A customer decides to modify his current installation by adding a new feature. (Our product consists of many individual features, some of them are not installed by default.)
5. Since version 1.0.1 arrived as a patch, the customer won't be able to add any of our features later on.

Personally I think that adding/removing features is always supposed to be possible, no matter if user's current version is installed as a major update or a patch.

Do you have any ideas how to add features to patched versions? Any kind of solution or suggestion would be highly appreciated!

Thanks in advance!

Regards,
Zsolt Kollarits

[Daniel]

Hello Zsolt,

To have a better view of your installation scenario, can you please send us the .AIPs (priject files) of your old product version, of your new product version and of your patch project to support at advancedinstaller dot com so we can test and investigate them on our side? Also, please forward us a step by step test case to follow.

All the best,
Daniel

[Zsolt Kollarits]

Hi Daniel,

Please find my sample projects (main, patch, and updater project) attached, I hope they will help you in reproduction.

The following steps should be performed:
1. Use Sample project 4 - Client.aip and create version 1.0.0 of the product. Note: Please review the path of Dummy.txt and Dummy2.txt under "Files and Folders".
2. Modify product version number to 1.0.1 and create a new build by "Keep existing".
3. Use Sample project 4 - Client - Patch project.aip and create a patch between your msi files. Note: You have to extract the exe files you created at Step 1 and Step 2 in order to get the proper msi files.
4. Create a valid update configuration file by Sample project 4 - Client - Update project.aip.
5. Install version 1.0.0 to an arbitrary PC. Note that only one out of 2 features has been installed and also that Dummy2.txt is still missing from your installation folder.
6. Modify version 1.0.0 and install SecondaryFeature too -> Dummy2.txt is installed now. Remove Secondary feature before patching.
7. Run "Updater for Sample project 4.exe" and install the available patch in a seamless way.
8. Repeat Step 7 by having version 1.0.1 now -> Dummy2.txt won´t appear in your installation directory after installing SecondaryFeature.

My latest investigation shows the problem happens only if you disable the Advertise option (Organization tab) for Secondary feature.

Could you please have a look at my samples?

Thanks in advance!

Regards,
Zsolt Kollarits

[mihai.petcu]

Dear Zsolt,

I followed the steps and couldn't replicate the behavior. After installing the patch I was able to modify the installation from the Control Panel in the same way as before applying the patch. "Dummy2.txt" file was installed as expected.

A first observation is that you need to keep all .AIP versions(e.g. project for version 1.0.0 and project for version 1.0.1) in subversion or a similar backup repository to avoid upgrades troubleshooting hell.

5. Install version 1.0.0 to an arbitrary PC.

"Dummyfile2.txt" component has the following condition set:

Code: Select all

Not VersionNT64

... this means that the component won't be installed on x64 machines, only on x86 machines.

Personally I think that adding/removing features is always supposed to be possible, no matter if user's current version is installed as a major update or a patch.

To clarify the forum topic: modifying an installation is always possible if the MSI containing all features was correctly cached on that machine and the cache was not removed afterwards. This behavior is regardless of the version or last update installed (patch or major upgrade).

All the best,
Mihai

[Zsolt Kollarits]

Hi Mihai,

Finally I could create a new sample project for you, which I hope to be more accurate.

Could you please perform the following steps:
1. Use Sample project 4 - Client.aip and set the product version number to 1.0.0.
Note: There are a few files added in "Files and Folders" that need to be reviewed in terms of path.
a) At "Application Folder" please set the path of the vncviewer to a random exe file.
b) At "INSTALLDIR32" please set the path of vncviewer to a random exe as well as dummy.txt to a random txt.
2. Please set the file version number of both vncviewer files to 1.0.0 too. This is very essential for reproduction.
3. Click on Build -> you have a proper 1.0.0 version now.
4. Modify the product version number to 1.0.1 as well as the version numbers of both vncviwer files.
5. Create Build 1.0.1 by using "Keep exiting" option.
6. Use Sample project 4 - Client - Patch project_x64.aip and create a x64 patch between your x64 msi files. Note: You have to extract the exe files you created at Step 1 and Step 2 in order to get the proper msi files.
7. Install version 1.0.0 to an arbitrary x64 PC. Note that feature called VNC won't be installed by default.
6. Modify version 1.0.0 and install VNC feature too -> vncviewer.exe is installed now. Remove VNC feature before patching.
7. Please also install your patch msp file now -> version 1.0.1 appears in Program and Features.
8. Repeat Step 7 by having version 1.0.1 now -> vncwiever won´t appear in your installation directory after installing VNC feature.

Please let me know if something is still missing. Thanks in advance!

Regards,
Zsolt Kollarits

[mihai.petcu]

Dear Zsolt,

I tested the steps on a completely different machine but unfortunately I was unable to replicate this. I sent you an e-mail with the video to confirm.

I recommend you to perform tests on several clean virtual machines which you can easily restore.

All the best,
Mihai

[Zsolt Kollarits]

Hi Mihai,

You are right, having the same configuration you have in your video is working fine even on my side.

The difference between my original config and yours is that your vncviewer file points to a local .txt file while mine points to real vncviewer.exe files. Personally I think reproduction is possible only if you use .exe files - at least I could see this problem with .exe files only.

After re-testing the config of your video, I set back all path values to real vncviewer.exe files to simulate a real environment. As a consequence vncviewer.exe file did not appear in the approrpiare folder after doing the same steps like before.

Could you please download various version of vncviewer.exe files and use them for testing?

For my tests I downloaded 4 different vncviewer.exe files
- vncviewer 5.2.2 32/64 bit versions from https://www.realvnc.com/download/viewer/5.2.2/
- vncviewer 5.2.3 32/64 bit versions from https://www.realvnc.com/download/viewer/5.2.3/
and used those 4 files in my sample projects.

If you tell me which tool you are using to capture a video - the output file of my current video capture tool is way too big to send you - then I'll also record the steps I used to do.

Regards,
Zsolt

[mihai.petcu]

Hi Zsolt,

I tried with the EXE files from the links and got the same behavior. I tried two version configurations for the EXE: "Get from file" and "User specified", both worked.

We are using TechSmith's Camtasia.

A side observation to your project: please keep in mind that you don't need to resolve the 64-bit folder location with a custom action. This is done automatically by Windows Installer. As described in the Paths of the folders in the "Files and Folders" Page article, the Program Files folder(ProgramFilesFolder) will be resolved to:
C:\Program Files
C:\Program Files (x86) on a 64-bit machine

Also, you should mark only the components you know are 64-bit and need to end up in 64-bit locations with "64-bit component" option from the Organization page. "vncviewer.exe_x86" doesn't need the 64-bit flag.

All the best,
Mihai

[mihai.petcu]

Dear Zsolt,

After further investigation I can confirm that the behavior you reported on this thread can be replicated as you described it initially, but only with versioned files (e.g. the 5.2.2 and 5.2.3 EXEs from your project).

We narrowed everything down in the attached (fresh) projects using the EXEs you provided. The test case is:
- specify the correct path to the EXEs and build all projects
- install version 1.0.0
- install patch 1.0.1
- modify the installation by adding "Feature"
=> the EXE file in "Feature" doesn't get installed

This is definitely a Windows Installer bug because the patch was applied without error but if you run the patch again after performing the test case above, the EXE gets installed in the expected location having the expected version.

In the log there is the following message when searching for the EXE name, just like the other users got in the topics linked from your initial post:

A subsequent patch will update the intermediate file, and then copy over the original.

We tried several other solutions but none were proven effective. Any feedback on this issue is welcome.

All the best,
Mihai

[mihai.petcu]

Dear Zsolt,

We found another setting that works: setting "Include whole files only" option from the Patch Details page in the patch project.

All the best,
Mihai

[Zsolt Kollarits]

Dear Mihai,

Indeed, vncviewer.exe file appears in our installation folder after
1. Installing version 1.0.0 of our sample project
2. Patching our product to version 1.0.1
however the "product version" of that particular exe file is still 5.2.2 instead of 5.2.3.

Please remember that I added vncviewer version 5.2.2 exe files to my "Sample project 4 - 1.0.0" and used version 5.2.3 exe files in "Sample project 4 - 1.0.1". Using the option of "Include whole files only" puts the old version of exe files and not the patched ones on the local drive.

Could you please confirm this? Also please let me know if you could achieve any progress regarding the Windows Installer bug.

Thanks in advance,
Zsolt

[Daniel]

Hello Zsolt,

We have tested the scenario using the sample attached by my colleague Mihai (fresh project.zip) and everything went fine. Can you please re-test the scenario using this sample and let us know if it works for you too?

All the best,
Daniel

[Zsolt Kollarits]

Hi Daniel,

Thanks for letting me know, I retested with your sample and it´s really working. Previously I tested it with my own sample, something must have been wrongly configured at that time as I managed to install the given exe file after patching my product.

Thanks for all the help during this thread! In case you get any updates from Windows Installer´s side regarding this issue, so that we could create our patches withOUT "Include whole files only" option, please let me know!

Regards,
Zsolt

[Daniel]

You're always welcome Zsolt.

All the best,
Daniel

[Philm]

First: Good work, guys to track that beast down and find the solution!

Just to summarize the long thread and two cents from my side:

I am working with Windows Installer for one and a half decade and I never trusted the binary patches. So, the setting "Include whole files only" is a conservative one, and I would always recommend to start with this. MSI patching contains very much traps, so it is worth minimizing them.

Moreover: Some experiments on the size gain with binary patches (admitted only with non executable files, but large data files) showed that the binary diff algorithm by MSI is very poor. In my example the gain was only 30%, but diff files are not compressable, and the normal .cab compression gains 30% while shrinking as well.
So at least in my example, the net advantage was nearly zero compared to "whole files".
Not counted, that binary diffs urge you to not work with cumulating patches (which I would recommend at the beginning too) or makes them at least a pain.

I don't think there are many people in the world who really can deal with MSI patches and build error-free ones. Nor is MSI itself error-free, only for the "mainstream" functionality it is working quite well- as you just have seen in this example- and "whole files" is the mainstream.
Everything what can help you to simplify patches, is recommended.

As an example: InstallShield guys are not under those. IS uses after 15 years still a completely wrong algorithm for creating patches (Haven't taken a look on AI's yet . Making diffs on two full standard MSI builds is the most dangerous method for creating patches (but the most used!), especially (but not only) because of the file sequences. And the means InstallShield has chosen to assure that the file sequences are the same for the second build, are not enough. Especially, sometimes the files of the second build are bound to a different .cab, and then the patch results in non-repairable installs.
And this is only one example. Not spoken on merge moduls used there, etc.