The COM extraction does register whichever file is set for extraction. However, the registry is remapped with the RegOverridePredefKey API (http://msdn2.microsoft.com/en-us/library/ms724901.aspx) to a private key prior to performing the registration. Since the registry is remapped, the file being registered on the machine beforehand shouldn't have any effect (also note that this can cause registration to fail if the file performs conditional registration based on registry data, since it is unavailable). Extracting at build is helpful if your COM data changes frequently. Otherwise, the IDE extraction should be sufficient. ... View more

The installation is failing during the ISXmlInstall custom action. However, from the log information, it is unclear why the custom action is failing. Can you try installing MSXML 4 on the machine and then run the installation again to see if that changes the behavior? ... View more

ICE84 indicates that InstallValidate is a required action. We would not recommend removing or conditioning out a required standard action from the sequence due to the unpredictable behavior that could likely occur. If InstallValidate doesn't run, at the very least the REMOVE property will not be set correctly during uninstall, in use files could cause reboots to function incorrectly or not at all, or receive runtime errors in those cases. ... View more

The log info above is already past where the original error occurred in the installation (rollback is running in this log info). Can you attach the full log file? ... View more

The AddLocal/Remove control events would be the simplest for your scenario. We've had other customer's use these without any adverse side effects during install or uninstall. Can you provide a little more detail on how you set up the Remove events and possibly post logs of the install/uninstall? ... View more

Using Method 2 from the article will break the SelectionTree control (which is used on the CustomSetup dialog). Also, moving CostFinalize seems to break the costing process on MSI 4.0 (Vista), which, if I remember correctly, results in runtime errors. Method 1 was added to the article after it was created and is now the preferred method of implementing setup types. The second method was kept for reference purposes. ... View more

Feature conditions are evaluated by the standard Windows Installer CostFinalize action. This action runs prior to any dialogs being displayed and initializes things like feature and component states while evaluating conditions. After CostFinalize has run, feature conditions are never reevaluated. As such, by the time any dialogs are displayed, changing property values that are used by the feature conditions will have no effect on what features are selected for installation. There are a few things you can try to work around this behavior: - Use the information in the following KB to progressively include additional features to be installed: HOWTO: Implementing Setup Types in a Basic MSI project - Use AddLocal/Remove control events conditioned on your properties to include or exclude features to be installed. - Use a custom action and the MsiSetFeatureState API to programmatically request the state of a feature. ... View more

You should be able to debug all InstallScript custom actions by adding the following registry information on the debug machine: Key: HKEY_CURRENT_USER\Software\InstallShield\ISEngine14.0 Value: DebugISCustomActions (REG_DWORD) set to 1 It's basically the same as IS 12 with an updated version number in the registry key. ... View more

Are you launching the child install from within the dialog code itself or from a script event? If it is being launched from the dialog, moving the LaunchAppAndWait call to a script event (like OnFirstUIAfter) should mitigate this behavior since no dialog would be displayed. Dialog repainting/refreshing is mostly handled internally by the engine. Unfortunately, there aren't any methods exposed at the script level for refreshing dialogs. ... View more

In addition to the information provided by Sheryl, there needs to be a request for the component to be installed or removed. A request is typically only made at the feature level; if no requests are made to the features containing these components (Request: Null for the feature in a verbose log), the reevaluate condition setting and the values of your properties will likely not have any effect. You could try adding a Reinstall event to the dialog containing the two checkboxes, and set the argument to the feature(s) containing these components, or All for all features. ... View more

By default, standard users are not allowed to browse for source media since the possibility exists for security issues. A system policy is available that would allow for browsing for source media for non-administrative users: AllowLockdownBrowse - http://msdn2.microsoft.com/en-us/library/aa367556.aspx ... View more

What was the action that was running when the ALLUSERS property gets deleted (look for an "Action Start" message)? This could help in isolating where/why the property is being deleted. Since the ALLUSERS property is undefined at the time the shortcut gets created, the behavior seen with the SHGetFolderPath resolution of DesktopFolder would be expected. I'm not sure why it's not installing to the path set by your custom action. If your custom action is sequenced after CostFinalize, you should use the MsiSetTargetPath API instead of MsiSetProperty. If it is sequenced before CostFinalize the action should work with MsiSetProperty. ... View more

If you are being prompted for a password this would indicate that the installation was launched with a user that is not a part of the administrators group (i.e. a standard user) and the requested execution level was set to require administrator. This being the case, it would be expected to be prompted for an admin password since the setup indicates it requires administrator access to the machine. You could change this to invoker or highest available, but if your installation attempts to write to any per-machine location (HKEY_LOCAL_MACHINE in the registry, Program Files on the file system, etc.) the setup will have insufficient privileges and will fail when run as a standard user or as an administrator with the execution level set to invoker. ... View more

Another change to the COM extraction was made in InstallShield 12 to use the Windows registry API RegOverridePredefKey (http://msdn2.microsoft.com/en-us/library/ms724901.aspx) instead of API hooking which DevStudio would have used. This change fixed some issues with COM extraction failing on some Windows 2003 installations and various other issues we were seeing with the old method. One side effect of this change can affect registration that attempts to read from the registry while the module is registering itself. For example, if the DllRegisterServer function in a DLL attempts to do a read from a registry key or value and then conditionally performs its registration based on the information returned, the new COM extraction method will cause no data to be returned. This is because we remap the "view" of the registry with the RegOverridePredefKey API. Are any of your DLLs that are failing to register performing any such conditional registration? Can you try adding the following key/value and see if the behavior changes? HKEY_CURRENT_USER\Software\InstallShield\RegSpy REG_DWORD: UseAPIRegistryHooks, value: 0 ... View more

You could either author entries into the RemoveFile table of your project that specifies the shortcut LNK files to be deleted, or you could use a custom action (VBScript, DLL, EXE, InstallScript, etc.) that deletes these files for you. You can find information on the RemoveFile table in the following article: RemoveFile Table - http://msdn2.microsoft.com/en-us/library/aa371201.aspx Another approach would be to author a major upgrade instead of a minor upgrade, which will uninstall the existing installation and then install the new installation, eliminating the need to author the RemoveFile table or a custom action. ... View more