I have a fairly new installation flow which involves a 32-bit Installscript bootstrapper which detects 32/64-bit and then calls the corresponding "main" installer package. The bootstrapper is designed to fail out with an abort statement after the call so that it doesn't register as an installed product itself. If it's relevant, the main installer packages are Installscript-MSI. The install works great, and if a user uninstalls via Add/Remove programs, all is well (it just calls the main installer's setup.exe directly). The problem occurs when users choose to run the original bootstrapper again to perform an uninstall. I have some installscript code to detect the presence of PROGRAMFILES^"InstallShield Installation Information"^{GUID for the 32 or 64-bit main package}^setup.exe. If detected, the bootstrapper knows it is being used for uninstall, so it calls that exe to initiate maintenance of the main installer, then fails out with an abort statement. I've tried this both with wait and no wait on the LaunchAppAndWait call to the other setup.exe, and either way the uninstall seems to proceed fine, but somewhere in this process the installscript bootstrapper becomes unusable again on that machine. Any further attempts to launch the bootstrapper result in the following error: Error reading setup initialization file I checked the temp folders and some were created, but were empty -- setup.inx and other familiar IS support files were nowhere to be found. I'm looking for advice not only for designing around this problem, but for fixing an existing machine which was affected by it. Thank you. ... View more

I've been experimenting with MSI chaining and there are a couple things that don't seem to be working for me (at least not the way the IS help describes the behavior): I have an MSI Installscript very light project as the "bootstrapper" and then I call either an x86 or x64 package depending on OS. I have install conditions set to either (VersionNT64) or NOT (VersionNT64) to choose the correct chained MSI. I do not want to stream the additional MSI packages into the first IS project. The help indicated I could set the path for the MSI to the typical MSI cache location for instance ( [LOCALAPPDATAFOLDER]\Downloaded Installations\{GUID}\ ). It turns out this causes the install to fail (generic error). However, if I manually copy the MSI to this cache location before install, the chaining proceeds with no error. Am I doing something wrong here? It seems like Installshield or MSI should handle this step (copying the MSI). Passing MSI properties and hiding secondary MSI packages from ARP seems to work fine, but when I uninstall the product (from the first package's ARP entry), it does not uninstall the chained MSI(s). My understanding was that Windows Installer wraps this all into one transaction, so I would expect that it would uninstall all the MSI packages together. Again, has anyone gotten this to work? Perhaps I just have it configured incorrectly. Note that there is a default removal condition of REMOVE="ALL" when you add a new chained MSI item, so I had left that in place. The initial project should have REMOVE="ALL" set when I uninstall it. Based on these issues I'm not getting the benefit I expected from chaining and will probably need to abandon it and find a different (probably much more complex) solution, so I hope someone can help suggest a solution to the issues mentioned above. Thank you. ... View more

I know this was either very complicated or impossible in prior releases of Installshield, but we were under the impression this capability was greatly enhanced in IS 2011, and have recently upgraded to take advantage of this. So far, between the release notes and forums I haven't seen clear instructions on how to accomplish this. To clarify, I'd like to maintain a single project (ideally using installscript MSI) which creates one output exe that could be installed either on a 32-bit or x64 OS. I've seen explanations involving setting release flags (where 32b/x64 components are filtered accordingly) and generating 2 separate output exe's. Is this the best available option even with IS 2011? Some details about what we have now which may help clarify what we need: -- both our 32b and x64 installers have dlls installing to the GAC (needing to be registered during install), to system32, and writing lots of registry keys in the HKLM branch. -- the x64 installer includes some 32-bit applications with accompanying registry keys meant for the WOW6432Node area of HKLM. These are generally duplicates of some of the x64 applications, and so there is no equivalent need in the 32-bit installer for these duplicates. While I expect certain files would need to be duplicated in 32b and x64 components, a great many of our files are exactly the same for both installers and we would really like to minimize the installer package size and not have duplicates of these files. I would really appreciate some guidance in understanding what our options are. Can we accomplish what I've described, or if not, what are the next best options? Thank you. ... View more