Try this link: http://helpnet.flexerasoftware.com It will take you to the company's HelpNet page, which will list documentation by product and year. InstallShield for Visual Studio and InstallShield Express, as I understand it, are subsets of the full product, so you might be most successful using InstallShield 2009 if you can. (Of course, that learning curve is also higher.) If your install requirements include creating a Windows Installer (MSI) package, I would also recommend looking at the documentation for Windows Installer online to get an understanding of how it works. InstallShield is a very good tool for creating those packages, but if you don't follow the best practice guidelines from Microsoft, you'll likely cause yourself issues down the line. Good luck. And this forum is a good one when you get the point where you have specific questions on what you're doing. ... View more

The "nested MSI' custom action type has been deprecated by Microsoft and is not recommended. ... View more

You need to look on the InstallShield site for information about migrating from IS 2008 to IS 2010. There are changes you may need to make depending on what type of projects you have. ... View more

If I understand this correctly, this is not a limitation of InstallShield, but a limitation of Windows Installer. An MSI package must be marked as either a 32-bit or a 64-bit package, so you can't build a single package that can be installed on either OS. What you can do, is create a single InstallShield project that will support both, using the release flags to include 32-bit and 64-bit components as appropriate. You will still have to build the package twice, once for each OS. ... View more

UPGRADINGPRODUCTCODE is only set in the nested uninstall of the old product, not in the install of the replacement. The action property in the Upgrade table item (default ISACTIONPROP1) gets set in the new install when it finds the related existing product, then UPGRADINGPRODUCTCODE is set on the uninstall's command line. So using "Not UPGRADINGPRODUCTCODE" as the condition should work for the scenario you describe. If you find that the CA doesn't run for the new install, or that it does run for the uninstall, then you have another issue and will need to examine your log files for the cause. ... View more

Try this: if the application is present, set your public property to any value; if it is not present, don't set the property at all. (Make sure it is NOT in the Property Manager.). Then set your type 19 (error) custom action to use the property. Error custom actions abort the installation if their condition evaluates to true. If your property exists (has a value), the condition will be true and the install will abort. If your property does not exist, the condition will evaluate to false and the type 19 custom action will not fire. Again, just use the property, don't check for a value in the property. (MYPROP, not MYPROP="1"). ... View more

So you're using an InstallScript custom action in a Basic MSI to copy files to the folder? Have you put the custom action in the Execute sequence run as deferred in System context? (That's needed so the action can run with elevated privileges.) ... View more

If I understand your situation correctly, you have a file that you install that is not accessible during costing, so your uninstall rolls back? Have you tried marking the file as permanent in the install (so Installer doesn't try to mark it for uninstall), then removing it either in RemoveFiles (with a dummy component, if necessary) or a custom action? (And are you sure you can't somehow "correct" the situation making it unaccessible in the first place?) ... View more

InstallShield should be able to retain the GUIDs across versions if: 1. you have dynamic links 2. each of those links excludes subfolders, that is, every subfolder has its own component 3. You have the Patch Optimization option turned on in the build, and point to the previous package. Since a component can only install to a single folder, if you include subfolders, InstallShield generates multiple components (with GUIDs) with multiple files (with individual GUIDs) and it is apparently unable to retain the GUIDs for the structure when you build a new version. ... View more

You can create an MSI that won't leave any "footprint" on the machine, so it will run every time as though it were the first time. Doing that, however, also means that you lose the ability to uninstall it. May I ask why you are using an MSI to install these keys rather that either putting the components in the other installation, putting them in a merge module, or even installing them as a custom action? Perhaps an MSI for these items isn't the most efficient way to go? However, to set the MSI not to leave a footprint, do the following: 1. Set a property ARPSYSTEMCOMPONENT with a value of "1" in the Property Manager to eliminate the Add/Remove Programs (Programs and Features) entry. 2. Set a condition on these standard actions so that they will not run so prevent them from writing the Windows Installer registry entries used to uninstall, run repairs, check for upgrades, etc.: RegisterProduct RegisterUser PublishFeature PublishProduct Also keep in mind that the MSI will still write registry entries for the components; because there will no corresponding entries for the product, the component entries will be "orphaned". ... View more

You might want to check the documentation, but I think that the AppSearch action (which is what System Search implements) can't find if a key exists, but can only find if a key has a value. In other words, don't look for the root key, look for a key or a string or dword that you know will be populated. the AppSearch action returns the value of the seach in the property, so if there is no value, the property doesn't get created. ... View more

When you say "Execute phase", are you talking about the Execute sequence? You don't have to do anything to run it; Windows Installer service runs it after the ExecuteAction in the InstallUI sequence. Maybe I'm not understanding you properly, but it sounds like you're trying to replace the basic functionality of Windows Installer. Have you taken a look at the Microsoft documentation for how to do upgrades? Most of it is inbuilt and relatively straight-forward. ... View more

I'm a little confused. If you're using a Basic MSI, why aren't you letting the MSI replace the new files? Why do you need custom actions to do that? ... View more

You can make an MSI act like a first time install every time, but it isn't particularly clean, and by doing so you will lose the ability to uninstall it, and will lose its in-built repair functionality. To do it, add a property called ARPSYSTEMCOMPONENT to the Property Manager with a value of "1" to prevent the app from showing in the Add/Remove Programs (Programs and Features) applet. Condition the following MSI standard actions so they will never execute: RegisterProduct RegisterUser PublishFeature PublishProduct If these actions don't run, Windows Installer won't have the registry keys its needs to recognize that your product has been installed, so it will always act as a first-time install. (But since it won't recognize your product, you won't be able to uninstall it.) Note also that the components in your product will still be individually registered, but those registry entries will be "orphans" because the corresponding product entries won't be there. I would suggest that you look into using an InstallScript project instead, if you can, as it is better able to install without leaving a footprint than an MSI. ... View more