The first two bits correspond to the UI selection you make. The only other bit (32) allows it to try and fail to remove a package that is not installed on the machine. When we released this feature, we implemented the support for these flags, but didn't think they were useful enough to document. I've heard a request for the reinstall bit before, so we may have to revisit this decision. ... View more

This is an interaction between two conflicting changes in the upgrade process, and you can fix it either of two ways: 1) Change the "Cache Path" from the Releases view, Single Image (or whichever you're building) > Setup.exe tab. The new default is [LocalAppDataFolder]Downloaded Installations. 2) Change the "Required Execution Level" (same view, same tab) from Invoker to Administrator. This will also cover for other changes on Vista if any custom actions in your installation require privileges they would not have when run under the Invoker option. Both of these changes should be covered on the various migration notes KBs linked on the Express forums. I think these changes became relevant as of version 12, but may have looked slightly different then. ... View more

The merge module aspect of this question is largely unimportant; however there are two important questions: Do the updated files in M1 1.1.0 cause any problems relative to the dependency of M2 1.0.0 on M1 1.0.0 - i.e. is the code side of the upgrade from M1 1.0.0 to M1 1.1.0 safe when other files are using it? Are the installation components authored correctly such that the upgrade doesn't put the machine in a bad state - i.e. is M1 1.1.0 identical to M1 1.0.0, except with updated versions of its DLLs, at least if it's installing to a shared location? If it's installing side-by-side, or in an application-private location, this question may be less important. If both questions are answered Yes - it's safe to update the files, and they will be updated correctly - then this should be fine. If the code is incompatible and they are installed to the same place, and/or if component rules are broken, this will likely cause a problem. ... View more

The help here is targeting the case where the chained package got uninstalled without removing the corresponding feature of the package which references it. It is possible to override the check that avoids running maintenance of the chained package, but it is not clear how one would do this and not tend to result in unexpected scenarios. Consider that an msiexec /i AlreadyInstalledPackage.msi will run maintenance. If you're willing to work through and test the various scenarios that enabling this option will expose, you can enable it by adding the flag ecoReinstallInstalled (16) to the Options column of the ISChainPackage table for the package or packages in question. Note that despite the name of the flag, it does not alter the command line, so will not pass a parameter like REINSTALL=ALL to the chained package. ... View more

If you mean the prerequisite exe files themselves show UI when they are launched, you will have to figure out and specify command line arguments to silence the exe. If the main installation is showing UI, you can address that with the command line parameters documented in the InstallShield help. (If the prerequisite exe files are InstallShield setups, they would also use the InstallShield command line arguments; if not, they may be different or not have any.) ... View more

You can determine some stages through MsiGetMode(), such as whether you are running in deferred execution, rollback, or commit. I'm not sure if it's possible to differentiate immediate execution of the execute and UI sequences though. ... View more

If this were a custom attribute value, it would be fairly easy to reference a property and change the property's value based on which feature was being installed. As is, I think you're right; the XML file changes isn't the best fit, as it expects too much all or nothing. If your way of splitting it up is working, it's probably the best you can do with the built-in functionality. If your changes get too complicated to maintain, though, you may find it easier to go to custom actions instead of (or perhaps in addition to) InstallShield functionality. ... View more

Huh, that is odd. My guess is this language pack was not available originally, and we missed when it got added. I've filed WO# IOC-000075161 to track our official resolution of this. In the meantime, if you need this now, your best bet may be to create it and perhaps the rest of the .NET 2.0 installation as prerequisites. ... View more

You might want to try setting the "Reevalutate Condition" option on this component in the upgraded versions. Without that, since it's not a new component, it uses the old status during a reinstall/upgrade. ... View more

I'm not looking at the 2008 SAB, but perhaps this will at least give a hint on where to look. It currently seems to reside in Redist\Language Independent\i386\ISP, at least assuming you're referring to the InstallScript stub. ... View more

If for any given installation choice there is only the one file, you should probably set this up as a single XML File Changes component. Then by attaching that same component to all the features in question (right click the features > Associate Components... in the Setup Design view), no matter which of the features are installed, the component with the XML File Changes will be installed. ... View more

So you've got two different DLLs which register various registry keys, some of which are separate and some of which are shared. From a development standpoint, the obvious theoretical solution is to separate off the overlap into a third DLL (which brings you to a state more like my previous post suggested), but I don't know how much sense this makes in practice. Perhaps someone else has encountered this before and can comment more usefully. The lack of shared counts on registry keys themselves doesn't make this easy. ... View more

The MSDN article references the SelfReg table and the corresponding actions built in to Windows Installer. The ISSelfReg table is an alternative provided by InstallShield; it has additional options including ordering by the Order column. ... View more

InstallScript projects do not offer any direct way to elevate in the middle of an installation. If you are trying to emulate the Windows Installer experience of elevating after clicking the Install button, the easiest way to do this (short of moving to MSI) will probably be to create two separate setups. The outer will run as invoker, and provide the UI and feature selection. The inner will run, probably silently or at least skipping the dialogs of OnFirstUIBefore and After, per settings passed in from the outer, and must be launched using shell execute (either with verb "runas" or on an "Require Administrator" setup) e.g. with LaunchApplication. If you're really sneaky, you can probably combine the two into a single setup and have it change its behavior depending on whether it's currently got the necessary privileges. Be careful to account for the case where someone is running as full administrator when they initially launch the setup, though, otherwise things could get really messy. ... View more

Depending on how often you do this, it might be worth investing in some form of virtual machine software on which to test your installs, so you can just revert when temporary failures block further testing. If you're just trying to save some time on a test machine (that is if you haven't already released this), it should be possible to just change your Product Code and optionally your Upgrade Code. You can do this under Organize Your Setup > General Information, category Product Properties. Also make sure you haven't set a Package Code, and that Generate Package Code is set to Yes (both on Prepare for Release > Releases, in the Express node). Then rebuild, and your next test should know very little about the previous. (There are still potentially some interactions at the file level that the above won't change, but hopefully they will not cause difficulties. The most likely difficulty after a change like this is files getting left behind at uninstall due to SharedDLL counts. If they do cause problems, look into resetting your test environment.) ... View more