Dear Advanced Installer Support Team,
I have a feeling custom action conditions are not working 100% correct, there might be a big in that area. We use Advanced Installer 14.5.1.
We have a custom action called DiscoverFirewallRules(powershell inline script) which is doing the following: it´s changing a value of a property from 0 to 1. For testing purposes I wanted to disable this custom action of ours by settings its condition to "FALSE" (I also tried to insert 0 into the Condition textbox).
The interesting thing is that in the installation log (L*Vx) file contains the name of our custom action in 6 places:
- the content of the whole powershell script appears in the log
- "MSI (s) (58:C8) [10:14:58:308]: Doing action: DiscoverFirewallRules"
- "Action 10:14:58: DiscoverFirewallRules."
- "Action start 10:14:58: DiscoverFirewallRules."
- "Action ended 10:15:07: DiscoverFirewallRules. Return value 1."
- "MSI (s) (58:88) [10:15:48:088]: Skipping action: DiscoverFirewallRules (condition is false)"
The last occurrence would suggest that the custom action was not running, but actually it was, because our property´s value has been modified from 0 to 1.
My question is: Why "FALSE" and "0" conditions are not turning off a custom action? That would be logical. Is it a bug in Advanced Installer.
For reproduction:
1. Create an "inline powershell script" custom action which is changing a property. For example contains a line like this: AI_SetMsiProperty YOUR_PROPERTY 1
2. Set its condition to FALSE or use 0
3. Install it on a PC from Command Line tool by using "L*Vx logfile.log" param
4. Analyze the log file -> confirm that the custom action was executed
Could you please try to reproduce this issue? Thanks in advance!
Best regards,
Zsolt
Suggested Articles
-
Zsolt Kollarits
- Posts: 342
- Joined: Fri May 29, 2015 10:36 am
Re: Custom action cannot be turned off
Hi Zsolt,
I tested the scenario that you suggested, but I couldn't replicate the issue. You may only reproduce this during an upgrade, which is normal in the case that I will describe below.
If, for example, that custom action is set to be always executed in version 1.0 of a product and never be executed in version 2.0, during the upgrade from version 1.0 to version 2.0, that custom action will still be executed during the uninstallation of the old version, but it will not be executed anymore during the installation of the new one.
Can you reproduce this if you first uninstall the old version from Control Panel and then install the new version as a fresh install? Also, can you reproduce this in a new project?
Best regards,
Eusebiu
I tested the scenario that you suggested, but I couldn't replicate the issue. You may only reproduce this during an upgrade, which is normal in the case that I will describe below.
If, for example, that custom action is set to be always executed in version 1.0 of a product and never be executed in version 2.0, during the upgrade from version 1.0 to version 2.0, that custom action will still be executed during the uninstallation of the old version, but it will not be executed anymore during the installation of the new one.
Can you reproduce this if you first uninstall the old version from Control Panel and then install the new version as a fresh install? Also, can you reproduce this in a new project?
Best regards,
Eusebiu
-
Zsolt Kollarits
- Posts: 342
- Joined: Fri May 29, 2015 10:36 am
Re: Custom action cannot be turned off
Hi Eusebiu,
Thanks for the tip, so maybe the uninstall procedure is making the custom action run. I´ll try to perform a fresh install then, so far I always triggered an upgrade.
Best regards,
Zsolt
Thanks for the tip, so maybe the uninstall procedure is making the custom action run. I´ll try to perform a fresh install then, so far I always triggered an upgrade.
Best regards,
Zsolt
-
Zsolt Kollarits
- Posts: 342
- Joined: Fri May 29, 2015 10:36 am
Re: Custom action cannot be turned off
Hi Eusebiu,
One of our customers just reported 2 problems for us with this "DiscoverFirewallRules" custom action. Basically he is just updating some machines from an older Therefore version to a newer one, machines have Windows 2008 R2 operation system.
1. On some of his machines the custom action is not executed at all. I´ll send you over a few files, including an installation log from him. You will see the custom action is really skipped, because its conditions are false. The .aip project files will also be sent to you in which you will see the following condition for the custom action:
(!TheServer=3) OR (!TheMFPManager=3) OR (!TheMobileManager=3) OR (!TheXMLWebService=3) OR (!TheWebAccess=3) OR (!ThePortal=3)
We intended to execute the custom action if any of these features were installed in base installation (before the upgrade) which is the case, because the customer is using all of these features, so they are always installed. It means the custom action should be executed, but as you can see it from the log, it is not.
2. There was a machine where - for some reason - the custom action was executed, but it failed. The customer told us he saw the following error message in the log file:
http://sqlserverandme.blogspot.com/2015 ... m-get.html
It means the command (get-netfirewallrule) we are using in our custom action (please check it in the .aip) is not recognized. We accept this, but we still don´t understand why the customer could not install the newer version of our product due to this error. On purpose we use many try-catch block in our custom action, the catch blocks are looking like this:
catch {$_ | Out-String}
So on purpose we do not throw any error to outside, all the errors should be handled and kept by the custom action. In this scenario, the customer could not install our new product version at all, he was blocked by the custom action, which is bad. We wanted to avoid this by try-catch blocks.
Could you please share your ideas with us. I´ll send you some files right now.
Best regards,
Zsolt
One of our customers just reported 2 problems for us with this "DiscoverFirewallRules" custom action. Basically he is just updating some machines from an older Therefore version to a newer one, machines have Windows 2008 R2 operation system.
1. On some of his machines the custom action is not executed at all. I´ll send you over a few files, including an installation log from him. You will see the custom action is really skipped, because its conditions are false. The .aip project files will also be sent to you in which you will see the following condition for the custom action:
(!TheServer=3) OR (!TheMFPManager=3) OR (!TheMobileManager=3) OR (!TheXMLWebService=3) OR (!TheWebAccess=3) OR (!ThePortal=3)
We intended to execute the custom action if any of these features were installed in base installation (before the upgrade) which is the case, because the customer is using all of these features, so they are always installed. It means the custom action should be executed, but as you can see it from the log, it is not.
2. There was a machine where - for some reason - the custom action was executed, but it failed. The customer told us he saw the following error message in the log file:
http://sqlserverandme.blogspot.com/2015 ... m-get.html
It means the command (get-netfirewallrule) we are using in our custom action (please check it in the .aip) is not recognized. We accept this, but we still don´t understand why the customer could not install the newer version of our product due to this error. On purpose we use many try-catch block in our custom action, the catch blocks are looking like this:
catch {$_ | Out-String}
So on purpose we do not throw any error to outside, all the errors should be handled and kept by the custom action. In this scenario, the customer could not install our new product version at all, he was blocked by the custom action, which is bad. We wanted to avoid this by try-catch blocks.
Could you please share your ideas with us. I´ll send you some files right now.
Best regards,
Zsolt
Re: Custom action cannot be turned off
Hi Zsolt,
1. Please keep in mind that this is the normal behavior in your scenario. During an upgrade, the uninstall of the old version and the installation of the new version are performed in two different sessions by Windows Installer.
Since you added the "DiscoverFirewallRules" custom action only in the new version of your product and used the (!Feature = 3) condition for it, which checks if that feature is installed locally, it checks if that feature is installed by the new version, not by the old one.
For the new version a condition like (&Feature = 3) would be true, but only if that feature will be installed by it. So, you can use that condition to execute your custom action in case the new version will install a certain feature.
2. I'm not sure why the custom action was executed, but failed on that machine. Even if you use try-catch blocks in your code, you need to make sure that the custom action will return the value 0 at the end, otherwise it will be interpreted as failure.
Best regards,
Eusebiu
1. Please keep in mind that this is the normal behavior in your scenario. During an upgrade, the uninstall of the old version and the installation of the new version are performed in two different sessions by Windows Installer.
Since you added the "DiscoverFirewallRules" custom action only in the new version of your product and used the (!Feature = 3) condition for it, which checks if that feature is installed locally, it checks if that feature is installed by the new version, not by the old one.
For the new version a condition like (&Feature = 3) would be true, but only if that feature will be installed by it. So, you can use that condition to execute your custom action in case the new version will install a certain feature.
2. I'm not sure why the custom action was executed, but failed on that machine. Even if you use try-catch blocks in your code, you need to make sure that the custom action will return the value 0 at the end, otherwise it will be interpreted as failure.
Best regards,
Eusebiu
-
Zsolt Kollarits
- Posts: 342
- Joined: Fri May 29, 2015 10:36 am
Re: Custom action cannot be turned off
Hi Eusebiu,
Regarding what you wrote down in Point 2: that info was really useful for us, thanks you for that.
Regarding Point 1: we don´t really understand why we can´t introduce a brand new custom action and let´s say check in its condition if a feature was installed in old product or not. Logically it should be possible, at least we think. Even if the custom action - obviously - is not executed by the "old" product while it´s being uninstalled (because it did not have the custom action yet). The "new" product should run that CA and should make use of the condition we set. There must be a way for the (brand new) CA to get some info about the "old" product -> about which features were already installed. If this is not possible yet in AI, then it´s a kind of new feature request. Our scenario is simply something that should be possible to do: introducing a new CA which runs on upgrade only if some features were added to the "old" product.
What do you think?
Best regards,
Zsolt
Regarding what you wrote down in Point 2: that info was really useful for us, thanks you for that.
Regarding Point 1: we don´t really understand why we can´t introduce a brand new custom action and let´s say check in its condition if a feature was installed in old product or not. Logically it should be possible, at least we think. Even if the custom action - obviously - is not executed by the "old" product while it´s being uninstalled (because it did not have the custom action yet). The "new" product should run that CA and should make use of the condition we set. There must be a way for the (brand new) CA to get some info about the "old" product -> about which features were already installed. If this is not possible yet in AI, then it´s a kind of new feature request. Our scenario is simply something that should be possible to do: introducing a new CA which runs on upgrade only if some features were added to the "old" product.
What do you think?
Best regards,
Zsolt
Re: Custom action cannot be turned off
Hi Zsolt,
I'm glad I could help you with point 2.
Regarding point 1, as I mentioned in my previous reply, you can check what features was installed in the old version, but not by using the (!Feature = 3) condition.
By default, all the features that were installed by an older version are automatically migrated to the new version. So, for a feature that was installed in the old version, the (&Feature = 3) condition will be true in the new version (which means that the same feature will also be installed by the new version). So you can use that condition for your custom action.
If you are afraid that the user could have manually changed the action of that feature in the new version, you can set a property based on the (&Feature = 3) condition right after the "Preparing" action group.
However, if the user will change the feature action by setting the "ADDLOCAL" property from the command line neither of the above solutions will work, so the only one that remains is to save the feature state in a persistent property when the old version is installed and check that property during the upgrade.
Another solution, which may be easier, is to use the "MsiQueryFeatureState" Windows Installer function to see the state a feature had in a specific version.
Best regards,
Eusebiu
I'm glad I could help you with point 2.
Regarding point 1, as I mentioned in my previous reply, you can check what features was installed in the old version, but not by using the (!Feature = 3) condition.
By default, all the features that were installed by an older version are automatically migrated to the new version. So, for a feature that was installed in the old version, the (&Feature = 3) condition will be true in the new version (which means that the same feature will also be installed by the new version). So you can use that condition for your custom action.
If you are afraid that the user could have manually changed the action of that feature in the new version, you can set a property based on the (&Feature = 3) condition right after the "Preparing" action group.
However, if the user will change the feature action by setting the "ADDLOCAL" property from the command line neither of the above solutions will work, so the only one that remains is to save the feature state in a persistent property when the old version is installed and check that property during the upgrade.
Another solution, which may be easier, is to use the "MsiQueryFeatureState" Windows Installer function to see the state a feature had in a specific version.
Best regards,
Eusebiu