You should be able to add it back in the Property Manager if it was deleted as a public property. Alternatively I believe (not 100% certain) you can sub TARGETDIR for INSTALLDIR as the target dir value is provided when you select your installation directory during the ui phase of the installation. You may also need to set the installation dir to TARGET dir under the installation information -> general Information section. I would strongly recommend trying to recreate the property first though. ... View more

I don't know the answer to that. You might try asking that same question over at the installsite forums. The admin there Stefan is extremely helpful. ... View more

Its possible you have all the dependencies but they are not available at the time your dlls attempt to com register. We had a similar problem and deleting and re-adding the components and resetting the flag the previous poster mentioned allowed it to work. I believe but cannot confirm that this reset the dlls to be the last thing that attempted to register correcting an order of operations problem that previously existed. ... View more

I am not sure how you would read the custom directory out unless you have it stored in a registry key somewhere. You could do a system search for the installation directory perhaps and then store that in the value INSTALLDIR By default the value of the destination folder should be [INSTALLDIR] so I imagine it should just work ... View more

MichaelU wrote: Ah, indeed, the whitepaper had less information than I remembered. The paragraph "Small and minor upgrades do not work by default" is most of it, and it also links to this thread with some more information: http://community.flexerasoftware.com/showthread.php?t=183641 But it leaves out the numeric details, so watch the values in the Options column of the ISChainPackages table as you change the UI setting in a sample basic msi project. Or just configure it how you want, and copy the values to your real file. Can anyone elaborate on those numeric details? I know 16 is supposed to be for ecoreinstallall or something along those lines. what are all the options supported and the corresponding arguments that need to be passed to make them all work correctly. I desperately need to be able to send a repair command to a chained msi ... View more

bump* anyone have any ideas this is still an issue for us. I would also like to have this upgrade on a minor upgrade but if that is not possible I can live with that. ... View more

Anyone know how to get MichaelU to read this? He seems very knowledgeable on the topic. ... View more

Michael, I tried setting that option in the ISChainPackage table that you have referred to but I am as of yet unable to to trigger the chained msi in maintenance or repair mode. I desperately need to be able to repair the chained msi when it is invoked in the parent one. What else do I need to do to make this work correctly? ... View more

Chaining the MSI packages is the way to go for sure. In the releases section click "Chained .msi packages" name it, point it to your msi. Give it the desired properties and ui level and profit. Uninstall handled automatically when your wrapper or parent msi is removed. ... View more

I would read the white paper on chained msi packages but it appears to no longer be available. The problem appears to be that it cannot call an installer process while one is already occurring. Attempting to move the location in the sequence to see if this alleviates the issue. edit ** this has not fixed the issue yet. I can call a nested install from a custom action if I schedule it after ExecuteAction in the sequence. But on the ExecuteSequence which is where I am scheduling the removal I get this error. Any advice is appreciated. ... View more

from my log file: === Verbose logging started: 5/15/2012 15:44:25 Build type: SHIP UNICODE 3.01.4001.5512 Calling process: C:\WINDOWS\system32\msiexec.exe === MSI (c) (C4:9C) [15:44:25:146]: Resetting cached policy values MSI (c) (C4:9C) [15:44:25:146]: Machine policy value 'Debug' is 0 MSI (c) (C4:9C) [15:44:25:146]: ******* RunEngine: ******* Product: {MYGUID} ******* Action: ******* CommandLine: ********** MSI (c) (C4:9C) [15:44:25:146]: Client-side and UI is none or basic: Running entire install on the server. MSI (c) (C4:9C) [15:44:28:146]: Failed to grab execution mutex. System error 258. MSI (c) (C4:9C) [15:44:28:146]: Cloaking enabled. MSI (c) (C4:9C) [15:44:28:146]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (C4:9C) [15:44:28:177]: Incrementing counter to disable shutdown. Counter after increment: 0 MSI (c) (C4:9C) [15:44:28:177]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1 MSI (c) (C4:9C) [15:44:28:177]: MainEngineThread is returning 1618 === Verbose logging stopped: 5/15/2012 15:44:28 === ... View more

phenrichs wrote: Have you looked in the Wow6432Node? I have a similar issue. I have a 32bit app (using installscript not msi) and I create all my keys normally in the wow but I need one set of keys to remain up in the 64bit area under SOFTWARE and I cannot seem to figure out how to get around the 6432 translation. By default in a 32bit installer the registry keys will auto go to the wow6432 location on a 64bit system. You cannot address the 64bit area in a 32bit installer. You can only address the 64bit area in a 64bit installer meaning you have to flag it as such. I believe but I am not certain a 64bit installer can have 32bit components but not the other way around. ... View more

Can you elaborate on your issue a little. I am not sure I understand the problem other than removing the product did not clean up your start menu shortcuts. Is there a condition where the shortcuts are removed properly or does it just never remove them? ... View more

Sorry if this is an obvious response but it sounds like you are saying you had an installer with dll lets call it "A". Then you recompiled the dll with a new version number and built a new installer with it and after you installed you did a comparison expecting the dll to be exactly the same sans version number; is that correct? If that is the case it should not be a surprise a binary comparison shows a difference between the two dlls. *edit Apologies in advance if I am misunderstanding your question ... View more