I have an issue where I have some custom action defined in wix project.
We are creating patch for our product. To create patch, when we build the code to generate msi on win server 2008 then upon installing patch the custom action doesn't get invoked(expected behaviour) but when we build the same code to generate msi on win server 2019 then the custom action is getting invoked.
The custom action is defined to update some ini file. Hence ini file is getting modified upon installing the patch.(which should not happen)
When I check the difference between the msi generated on 2008 and 2019 then i could see only below difference.
I checked the difference between the tools installed on 2008 and 2019, i found there is difference in wix toolset version on both the machine(2008 has 3.11.0.1528 and 2019 has 3.11.2.4516)
can someone please let me know what could cause such issue?
Any help is highly appreciated. Thanks.
Check InstallUISequence and InstallExecuteSequence table for the problematic custom action in msi file. Look for the Condition of the custom action. Somehow, the condition evaluating true in Server 2019. You need to debug msi log to find the root cause.
Related
In WIX project, one feature is defined which updates files and its content. When I build the project on windows server 2008 and the same is build on win server 2019 then I can see the wix property for that feature gets modified. Due to which the when the patch(build on 2019 server) updated the content whereas when patch(build on 2008) doesn't update the file(expected behavior)
Please find the MIS log(For patch created on win 2008)
MIS log(for patch created on win server 2019)
What is the reason behind changing the request and Action property for feature if the project is built on 2019 server?
Note : Not sure but this might be causing the custom action to be called in later case which is undesirable.
Any suggestion will be highly appreciated. Thanks
I have setup created with InstallShield 2015 Basic MSI project.
While installing the setup before installing the files the setup hangs for minutes and even more and in the MSI log file I get these kind of lines.
MSI (s) (38!98) [15:58:41:394]: SECREPAIR: Hash Value for the file:program files\AAA\BBB\hwlib\S7IO\IOBG\IOBG17547.XML is: dXJdIksL5KIA2clSOFHHLMzqgxrtSxCj1B9WpZEe7MA=
I‘m not sure there is a connection to Microsoft KB2918614, KB3000988 and KB3008627 since in my case setup just hang but doesn’t fail.
I tried several workarounds to solve it like :
Uninstall these updates and update the product code under
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer\SecureRepairWhitelist] but it doesn't help in all cases..
Is there a settings in InstallShield I can use to avoid this problem ?
If there is a connection to the 3 Microsoft updates above do Microsoft intend to release another fix for these issues ?
I have the same problem, it is related to KB3072630. I the files are located e.g. on DVD-Drive then the hash generation takes a long time but it finally works.
InstallShield blames Microsoft.
I have a support incident pending at Microsoft Support.
I am creating an MSI package using Visual Studio and I have added in the SQL Express set up, it all works fine, except I would like to automatically open the SQL Express when the application has finished installed.
I did a bit of investigating and saw an option in Visual Studio in the properties window for the Setup named PostBuildEvent. Can I add a custom macro here to boot the SQL Express installer? If so, how would I go about doing this? And if not, does anyone have any suggestions on how I could make this work?
Any help would be GREATLY appreciated, thank you!
The post build event runs on your machine immediately after the build of the MSI file completes. It will run code immediately after Visual Studio is completes building the MSI. It will not run when an end-user installs the application.
To have the installer run code after the end-user installs the application use a Custom Action.
I have an legacy installation from a DotNet 1.1 application (with Visual Studio 2003) that will not deploy the msflxgrd.ocx file on the FIRST installation on Windows 7. If I uninstall the MSI and then run the same MSI again, (and future installations on the same laptop), the msflxgrd.ocx file deploys. At first I suspected that it was a regsvr32 issue, but since there is no file to register, it seems to be more of a deployment issue. I have administrative rights on the machines.
I have links to the MSI logs here:
Is anyone able to help?
Thanks!
My previous answer was to explain what was going wrong. This answer will be how to fix it.
InstallShield distributes a Merge Module for this control that contains version 6.0.84.18. However, it seems that this merge module is old and doesn't include a security update that was released by Microsoft a few years back. See the thread:
Updated Merge Modules for MS08-070 Security Bulletin
In the thread Mike Marino tried to get updated merge modules from Microsoft but was told:
Microsoft will not be providing Merge Modules for these. They
recommended that users either build their own MSMs or include these
files in their own MSIs.
So here is what I would do. Make sure the msflxgrd.dll is the latest version from MS08-070 (6.1.98.14) or newer. Author it into your installer in the SystemFolder directory. Mark it as Permanenet = true. Set the Register attribute to vsdraCOM and set the SharedLegacyFile = true.
Rebuild your installer and test your upgrade scenario again. You should be good to go.
From what I see in Log 1, the machine is not as clean as you think. FindRelatedProducts is finding a previous installation of your product and telling RemoveExistingProducts to uninstall it before installing your new version.
I've seen situations when the component rules are violated that MSI thinks a file doesn't need to be installed but the file then gets uninstalled by the removal of the product being upgraded and the file ends up not being installed. By uninstalling and reinstalling you break that up into two steps so that when the second install evaluates the need for the file it comes back as yes and gets installed.
The fact that this is an OCX COM server is just a coincidence and not really relevant to the real problem.
I'd need the MSI already installed and the MSI upgrading to give you specific remedys.
Action start 14:55:44: FindRelatedProducts.
MSI (s) (A0:18) [14:55:44:119]: PROPERTY CHANGE: Adding PREVIOUSVERSIONSINSTALLED property. Its value is '{08D8BF6E-E399-4B8A-8B8D-7DFF68F81131}'.
MSI (s) (A0:18) [14:55:44:119]: Skipping action: ERRCA_CANCELNEWERVERSION (condition is false)
MSI (s) (A0:18) [14:55:44:119]: Doing action: VSDCA_VsdLaunchConditions
Action ended 14:55:44: FindRelatedProducts. Return value 1.
Visual Studio Setup project:
I have to check certain system requirements before my setup runs. (Read some stuff from a file and then continue or cancel the setup depending on the content)
I tried adding a custom action with BeforeInstall but it gets executed too late. The old setup has already been uninstalled when my custom actions BeforeInstall gets executed.
How can I tell the setup to check certain system requirements before anything else gets executed/installed/changed? Is a custom action the wrong way to do it?
Thanks
Visual Studio Setup Projects abstracts the scheduling of custom actions as Install, Rollback, Commit, Uninstall and doesn't expose the ability to schedule a custom action in the way you'd need it to run.
The only way to do this would be to use a WiX Merge Module to get the control you need and then merge it into your VDPROJ installer.
Also you should know that VDPROJ is so horrible that Microsoft has removed it from Visual Studio 11 and told customers to use InstallShield Limited Edition (Free) instead.
It is possible. I had to do this also, I came up with the following solution:
I've created a custom installer and overwrote the Install() Method.
You can now check the system information via WMI and throw an exception if they dont match your requirements, the installer will perform a clean rollback.