Hi, I got a problem with several LaunchApplication calls in Custom Actions of a BasicMSI project. They all look like this:   nCallResult = LaunchApplication("cmd.exe", "/C \"C:\\MyDirectory\\myscript.cmd\"", "C:\\MyDirectory", SW_HIDE, 600000, LAAW_OPTION_WAIT_INCL_CHILD);   Now this is the weird part: As long as the cmd script finishes within the timeout (< 10 minutes in this case), everything works as expected. If the cmd script takes longer however, the LaunchApplication call will wait indefinitely. In my case, I could see that the cmd script was finished after 13 minutes. The whole installation however was stuck because LaunchApplication would never return. To me it seems that the timeout somehow "disconnects" the installation from the created process, but doesn't stop the execution of LaunchApplication. My expectation would be that as soon as the timeout is reached, LaunchApplication would return and my variable nCallResult would contain the corresponding error message. Am I doing anything wrong? ... View more

Hi there, I once again ran into a little problem with my BasicMSI installation (InstallShield 2019 Professional). I need to determine the size of a folder containing several huge files (can be up to 30 GB per file and >300 GB for the whole folder). The standard code snippets you can find everywhere are usually only capable of handling a total folder size < 2 GB because that's the limit of a single NUMBER variable. I found the function GetAndAddAllFilesCost and tried the following (source and target directory are same since I only need to check size without moving files): GetAndAddAllFilesCost(szDirectory, "*", szDirectory, 0, nvSizeHigh, nvSizeLow, nvCostUninstall); For "small" folders (e.g. 500 MB total size) it works perfectly returning 0 for nvSizeHigh and the folder size in bytes for nvSizeLow. For the huge folder (3.3 GB in my test scenario with no single file exceeding 2 GB) it still returned 0 for nvSizeHigh and -742141952 for nvSizeLow. Obviously it still tried to store the whole value in nvSizeLow and then resulting in an overflow continuing from -2 GB. The result is pretty much where 3.3 GB would bring me. To me it seems to be a bug in InstallShield since the function according to documentation should be able to handle large numbers; apparently it only separates high/low values for a single file, but then tries to sum up high for all files and low for all files which can't work. Is there any better working way without having to manually do the calculation between high and low? If I'd have to manually sum up the values and consider overflow it would end up very ugly. ... View more

Hi, I have a little problem trying to build a minor update for my application. Installation of the minor upgrade works fine and I also followed all "rules", adding several new components but not removing any existing feature, component or key file. The problem arises when I try to uninstall the application. Once the minor upgrade is installed, uninstallation doesn't work anymore and always asks for the original MSI file (not the one of the upgrade). Setup and the Upgrade are different InstallShield projects but with the same name, upgrade code, product code. Also the features and components are identical (except for the new components), so I think this shouldn't be an issue. Major upgrades work well with the same upgrade project. The big difference to major upgrades is that in my minor upgrade I don't ship all the files but only the changed ones. I was wondering if the problem could come from components using dynamic file linking. As far as I could read, with dynamic file linking a random file will be chosen as the key file - and of course, as I only ship a few files with my minor upgrade, chances are high the file isn't there in the upgrade, so the chosen key file might be a different one. Am I right that this is the cause of my trouble? Would there be any solution to it except for always shipping major upgrades with all files included? Unfortunately I can't get rid of dynamic file linking for my project. ... View more