Did you ever figure this out? I have a Basic MSI project that does not launch the msi. I can launch the msi manually. Thanks ... View more

I officially don't understand this issue. Changing the upgrade setting to "install then remove" does in fact eliminate this problem. However, using the default sequencing for "uninstall then install new" just doesn't work right. Nothing has changed with this installer pertaining to this file in the past several releases but it suddenly stops installing the upgrade correctly? I guess using "install then remove" is what we'll have to do to make it work right. ... View more

Thanks Robert. I didn't realize the <> notation would work outside of InstallScript functions. This works exactly how I was hoping. ... View more

After a lengthy session of "trial by fire" with FeatureCompareSizeRequired() I've discovered the following conditions must be met for this function to succeed: 1. Every component must have a valid Destination ( , etc.) set. 2. The Destination must be set even if the component belongs only to a Feature that has been forcibly disabled by FeatureSetData() prior to FeatureCompareSizeRequired(). 3. The Destination, say , must include a drive letter. "\Some\Path" does not work, regardless of the source location of setup.exe (desktop, network), despite being a valid Windows path. 4. The Destination does not need to exist at the time FeatureCompareSizeRequired() is called. We were using IISROOTFOLDER as the base path to some of the server-only components but InstallShield provides a default IISROOTFOLDER path of "\" if IIS is not installed. ExistsDir() returns success when it is given "\" as the input path. Using IISROOTFOLDER works great on our server installation as IIS is already validated by other means but on the workstation installation IIS is expected to not be installed (but is fine if it is installed). The default value provided by InstallShield actually gets in the way more than it helps when IIS is not installed (though I understand why it is set to "\"). Conclusion The "not enough space" error message returned from FeatureCompareSizeRequired() is vague and misleading: worthless. The documentation on this function is vague and virtually worthless as anything more than an API reference. One painful day doing battle with InstallShield has finally come to a close... ... View more

The FeatureSetData page has a link to the topic "Specifying Features and Subfeatures in Function Calls", which might help. The idea is that you give the full path to the subfeature, as in "Desktop Software\\Feature 1". ... View more

Assuming you've already defined these additional folders in the IDE, the script function FeatureSetTarget can be used to change the target path referenced by the folder name. If you only need these to be changed in a first time install, the calls to FeatureSetTarget can be made in the OnFirstUIBefore event in your script, perhaps after prompting a user for a desired path if needed. ... View more

I haven't used it, but with patch optimization you can point the build at the previous deployment so that it can do the differencing... you may want to look into that. ... View more

Am I the only one who has experienced this with a dynamic file link in a pure MSI package? Seems like a flaw in MSI or in the InstallShield interface. I can't fathom that every pure MSI package out there (created from InstallShield, of course) manually names each file in a component. ... View more

I knew it was going to be something really simple that I was overlooking. I thought there was a flag somewhere but I just couldn't find it. Thank you! ... View more

I finally figured out a way to make this work. What I had to do was add a key file that would be guaranteed to change from one build to the next. I also had to rearrange the the source files directory structure to accommodate both a static and dynamic link in the same component. Once I set the key file the upgrade has been working exactly as it should. ... View more

Hi, You can do a System search for a component guid or product guid for Product A. If it finds a guid in the registry , you can then insert a custom action to run only if the GUID is detected. The custom action warns the users, and then exits the installatino. ... View more

I guess we could just launch the EXE like we are now and not try to be preemptive. The EXE we launch is not really a full-blown EXE. It's actually a Wise Script installer that's running as a plain executable (i.e. a wrapper executable). The author needed a solution and he only knew Wise Script at the time so that's what we got stuck with. I'll have to investigate the possibility of either doing this in a regular executable or possible a DLL call that gets added to our installation helper DLL. ... View more

Thanks for the response. I've been looking at the documentation on the rest of the code necessary to change the Product Code but all of the documentation made reference to "run GenerateGUID" but I had not seen anything that detailed how the function worked. ... View more

To test a theory of whether this was a project issue or a global issue I create a brand new InstallScript MSI project. I assigned basic properties INSTALLDIR and a couple other settings. I have finally tracked down the setting that is causing my directories to become nested. If the "InstallScript User Interface Type" is set to "New Style" the directories become nested. Changing it to "Traditional Style" fixes the nesting problem and the directories become siblings, as expected. Anyone familiar with the internals of these two have any further information about why this setting would cause siblings directories to become nested? ... View more

I figured it was something along these lines. I've decided to rearchitect how we do these tasks and have multiple CAs, one for each task, and a complimentary Set Property CA for each. This will compartmentalize the installation a bit more and probably moves this installer more in line with expected behavior for MSI installers. ... View more