LanceRas wrote: But I need to be able to dual sign the MSI before it is wrapped in the Setup.EXE. Details in regard to why dual sign MSI is not supported was provided by Josh Stechnij (Software Engineer - Flexera Software: InstallShield Team) in another thread. https://community.flexerasoftware.com/showthread.php?218163-Codesigning-using-SHA-2-SHA256&p=507778#post507778 ... View more

I did some additional testing and noticed if specify path(s) via the -o flag it will not also include the default locations when looking for merge modules. For example, if the project references two different merge modules (different network paths) and only included path for one via -o while relying on the default location for the other, it will fail. Though, I view that as a good thing as it ensures that will always use the merge module that is specified in one of the paths and not whatever is local since the network path may have newer build. Again, multiple build machines are involved and the MSI project may or may not be built on the same machine as the merge module(s). This answers my second question, though the first question still is valid. Can network repository be used with standalone build, if so how is the network repository path specified without the IDE? Or is the -o flag the way to go? ... View more

For completeness, I also tested the version values regarding the Upgrade table. It does not matter if padding is used or not, the upgrade entries all work as expected. This is true even for scenarios when the installed version had padding and upgrade entry did not, and vice versa. In summary, there appears to be no problems with the short or long version strings with one exception: if you are doing your own string comparison such as an install condition (see previous post). If you think you may need to include a version in a condition, then perhaps consider padding otherwise it is pefecttly fine to use the no-padding approach. ... View more

I did some simple testing with install condition. As expected, string comparisons require the extra padding to work properly. Otherwise "1.10.0" is treated as less than "1.9.0". As such, I'll probably always add extra padding. What are others out there doing? ... View more

We are in similar situation where desire DirectX prerequisite instead of merge module / InstallShield object. We ultimately created our own prerequisite for the web installer available from Microsoft. Anyone else have thoughts on this topic as to best option? ... View more

Thanks for the suggestion. Though I am not sure that will work in all cases. In particular, the scenario of a major upgrade of one of the products while another product(s) was also found. Still would want RemoveExistingProducts to execute in order to remove the currently updating product. RemoveExistingProducts action only runs once and not once for each product to uninstall, so I don't think that adding condition would help. (I could be wrong, but those are my initial thoughts). Taking a step back, the MSDN documentation for RemoveExistingProducts action: The RemoveExistingProducts action goes through the product codes listed in the ActionProperty column of the Upgrade table and removes the products in sequence by invoking concurrent installations. That may be the answer. I could conditionally clear the respective property that should not be uninstalled after FindRelatedProducts but before RemoveExistingProducts. All in all, I think it would be much preferred to have the ability at build time to include/exclude major upgrade items accordingly instead of these extra steps. Thoughts on this feature request? Or maybe it is rare to have related products within same installer project that ultimately need to be treated as unrelated? ... View more

Windows Installer will cache the MSI tables within a system folder so it can perform uninstalls accordingly. However, none of the binaries are cached meaning cannot perform maintenance unless browse to the install media or it is cached on the target computer. I believe you are referring to the setting in the Setup.exe tab under Releases view within InstallShield. Note that it will only be enabled for relases that do not have the msi file available in the same folder as the setup.exe - for example a compressed build where the only output is a single setup.exe. Specifically, the help says it will: Cache the .msi file and other installation files on the target system for use with application maintenance and repair. The default location is [LocalAppDataFolder]Downloaded Installations\ . On a Windows XP it will be C:\Documents and Settings\ \Local Settings\Application Data\Downloaded Installations\ and on Windows 7 it will be C:\Users\ \AppData\Local\Downloaded Installations\ . Generally I will modify that path to also include our company and product name. I have follow-up question to others in the community. When are these cached msi's deleted? They appear to remain even after uninstalling. Additionally, since package code changes for every build (configurable within InstallShield) there will be many cached msi's if many installs occur. For frequent large installations this can add up to several gigabytes over time. ... View more

Thank you for the feedback, including the link to Microsoft's documentation for further understanding. I named my shortcut "IS 2011" and it works great. Thanks again. ... View more

I found an additional thread that discusses IS_MINOR_UPGRADE http://community.flexerasoftware.com/showthread.php?t=138411 ... View more