Firstly, check the property dump at the end of your installation log and see if the value of your property is what you would expect, if not then your logic is wrong somewhere. If the above is correct then you need to look at the sequencing. The installer decides whether or not to install a feature based on its install levels at the cost finalize stage. If your property is being set after that then it won't take affect ... View more

That's fairly straight forward. You should be able to open the older MSI directly using installshield. For what you want, you shouldn't need the original project file. To start from a clean slate, it's best if your package code, product code and upgrade code differ from any of those in the previous msi. Then in the upgrade table, add the upgradecode from the previous installation. If you specify the attributes column as 256 then this will do a complete uninstall before installing yours. Hope this helps 🙂 ... View more

If you need to be even more specific and use an X64 processor and not to include alpha processors then you can use the Msix64 property instead. (e.g. Msix64 or not Msix64) ... View more

Well if you extract com data instead of self registering. It's one or the other, you don't do both. Extracting com data is writing the registration information in yourself. Then you shouldn't get the error dialogs. ... View more

They need to be registered with Installshield. The easiest way to add that reference is to right click within the redistributables view, and select browse for merge module, browse to the one you added to your merge modules folder and you're done. Bear in mind though that you may end up with two merge modules with the same name because it's the product name that shows not the filename ... View more

Self-registrering files can cause all kinds of problems due to the way they are written by the developers of your application. For this reason alone, I would go as far as saying that self-registration is a bit of a bad practice and I guess Flexera agree for the fact that it defaults to off. Instead, I would add the files to the com tables etc yourself. Now before you panic Installshield can do this for you. Simply turn off the self-registeration, add your file to a component (in a component all by itself is good practice), make it the key file, right click the file and select Extract Com Data for Key file. Hope this helps ... View more

It sounds like the installation has been authored to run for all users on a machine rather than the option just for me. But strangely it sounds like it's defaulted the other way. I presume you've extracted this from a setup.exe to be able to deploy it and the setup.exe passed through the all users property for you. Run the installation like this and see what you get: msiexec /i " " ALLUSERS=1 You may also be missing other properties that the setup is passing through though so it may be trial and error ... View more

Is anything left in these folders? If the application creates files when it runs then the installer will not remove these because it didn't install them and doesn't know to remove them and will leave behind the folder structure that they are in. If you application does do this and you do want to remove those files, you can provide an entry in the removefile table. MSDN provides details on the entires to add to this table here: http://msdn.microsoft.com/en-us/library/aa371201(VS.85).aspx. Please note that the file column can contain wildcards such as *.log or even *.* ... View more

A checkbox is checked when a property is present and it's unchecked when the property is deleted. Add the associated property with any value to the property table and it will default to checked ... View more

you're right 😮 I should learn to read more carefully :rolleyes: ... View more

what type of project? ... View more

Actually for a basic msi project and vbscript custom actions it's myinstallationdir = Session.Property("INSTALLDIR") you don't need to create the Session object. However if your custom action makes any changes to the machine best practice is to make this action deferred and if it's deferred you don't have access to most properties so it's a slightly different mechanism to get the installdir. To do this: - Create a set property custom action, call it whatever you like and i prefer to put these just before costfinalize -If your other custom action is called SetStuffCA then in your set property action set the property name SetStuffCA. Then set the value to [INSTALLDIR] -In your custom action instead of referring to INSTALLDIR, you refer to CustomActionData. This will contain the values passed in from the set property action. If you have more than one property to pass to your custom action you may want to set the property to something like this [INSTALLDIR],[ANOTHERPROPERTY],1,test,[SOMEPROPERTY]. Then all you need to do is split the value at the commas within the vbscript ... View more

Well if it's a straight forward double click then you'd just be populating those properties using the dialogs wouldn't you? ... View more

The command line would be something like: msiexec /i "c:\myinstaller.msi" MYPROPERTY1="myvalue1" MYPROPERTY3="myvalue3" /qn Now you'll see that i have only specified the two properties that i need to change. All the properties will be stored in the property table with their values all set to default. The command line i provided will only override those defaults for the two i provided. Just make sure you make a good guide for administrators to follow. One other way you could do it is to explain to the administrator in your guide how to create a transform file using orca which is also an answer file of sorts ... View more