I am aware of one caveat that will bite you, and it is subtle. It has to do with multi-feature membership of the built *.msi package. If you use release flags to include a component into features that are mutually exclusive across your builds, you are probably OK. However, this situation is what you have to watch out for: [LIST=1] Component A belongs to multiple features (feature A and feature B) User selects custom install, selects both Feature A and Feature B User changes mind and deselects Feature B Component now doesn't get installed, even though it belongs to Feature A, which is getting installed. What is happening here is that the SelectionTree dialog performs a "Select" operation that toggles components underneath each of the features. Since the last operation in the above example is a "Toggle Off" for all components under Feature B, you end up losing Component A. This is a strong case for a Common feature that you just put some conditions on. If certain builds need to not install the Common Feature, then put a condition on that feature that checks against the ISReleaseFlags property for certain release flags: http://helpnet.installshield.com/installshield16helplib/IHelpCustomActionsReleaseFlags.htm You can also do this on a Component level. Of course, once you start getting into multiple features with different destinations, at a certain point it starts to make sense to just use the DuplicateFile table, or multiple components, etc. ... View more

I would first try a sanity check and do a binary diff between the file on the InstallShield machine: \redist\Language Independent\OS Independent\setupicon.ico And the file as mentioned on the build machine: C:\TeamCity\buildAgent\work\258316e5d2bb2bf4\icon.ico My guess is something is getting screwed up along the way, which chokes the build process. If it appears identical, then at least we can rule out file format as the issue. ... View more

It may help if you mention the version of InstallShield you're seeing this with, and also post an icon file (or a file that contains an icon) that produces the error. I've seen corrupt icon files as well that cause this issue, or sometimes even crash IS. ... View more

I just was directed to this issue myself today. Here's what I found helped: 1. Navigate to Dialogs view 2. Choose to 'Edit' the "SQLServerSelectLogin(Ex)(2)" dialog 3. Go to the properties of control "ControlId_1200" 4. Change Tab index to 1 ... View more

In fact, I found that it fails catastrophically exactly at 2050 characters, which you can see yourself below: [CODE]function MyFunction(hMSI) STRING sBuffer[8000],sCount,sError; number nSize, i, nResult; begin nSize = 4096; for i = 1 to 4096 try nSize = 4096; nResult = MsiGetProperty(hMSI, "MYPROP", sBuffer, nSize); if(StrLength(sBuffer) = 0) then NumToStr(sCount,i); MessageBox("Lost property value at char count: " + sCount,0); else //We don't make it to this point 2051 times, it quits on the next MsiGetProperty() MsiSetProperty(hMSI,"MYPROP",sBuffer + "X"); endif; catch NumToStr(sError,Err.Number); MessageBox("2050 char error: " + sError,0); endcatch; endfor; end;[/CODE] This is in IS2010 and 2012 (although I am told by a colleague of mine that it seems fine in IS2013 SP1). Known issue, with a known fix maybe? Cary R wrote: Bumping this thread... Robert, I note that you've set the buffer to 2049 in this example. Is there a particular reason for this? (I ask because the script engine seems to crash when you try to MsiGetProperty a value that is 2050 characters long...) ... View more

Bumping this thread... Robert, I note that you've set the buffer to 2049 in this example. Is there a particular reason for this? (I ask because the script engine seems to crash when you try to MsiGetProperty a value that is 2050 characters long...) RobertDickau wrote: Assuming you're asking about InstallScript, I can verify that 500 characters works in InstallShield 2009: create a registry key HKCR\...MyKeyName with a string value LongValue with 1,000 characters. In the MSI project, create a system search that reads the value into a property PROP_WITH_LONG_VALUE. Create an InstallScript custom action--- [code]#include "ifx.h" export prototype GetLongValue(HWND); function GetLongValue(hInstall) STRING sLongValue[2048]; NUMBER nBufferSize; NUMBER nReturn; begin nBufferSize = 2049; nReturn = MsiGetProperty(hInstall, "PROP_WITH_LONG_VALUE", sLongValue, nBufferSize); SprintfBox(INFORMATION, "Long Property Value", "%d (%d) -> %s", nReturn, nBufferSize, sLongValue); end;[/code]---and schedule it after the AppSearch action, and it seems to work... ... View more

dudelove wrote: Hi Cary, Thanks for your reply Yes the merge module is the only thing under its feature. Could you step me through implementing what you described? This is all very new to me. Cheers It is pretty simple: 1. In the latest project file that you're using to build the patch, create a new custom action of type "Set Property" 2. Set the target property to REMOVE, and the value to the internal name of the feature. (This will be what is in the Features view of InstallShield) 3. Sequence the custom action as the First Action of the Execute Sequence, and give it a condition of 'PATCH' 4. Next, create, again, a Set Property custom action 5. This time target the ADDLOCAL property with the feature name as the value 6. Sequence it after the action from step 3, with a condition of MSIPATCHREMOVE 7. In the properties of the custom action, find the property for "Run during Patch Uninstallation", and enable it. Now the merge module will get reinstalled when you uninstall the patch from Add/Remove programs as well as uninstallling during the patch installation. ... View more

dudelove wrote: Hi everyone, New to InstallShield and BasicMSIs. We have a base installation that includes a merge module (licensing software) We are now releasing a patch to update some of our software including a new version of the licensing software that is no longer provided via a merge module but now a prerequisite. I can get the new prerequisite to install correctly, however I do not know how to uninstall the previous version that was installed via merge module. The new version of licensing software installs to a new file location so it does not 'overwrite' the old version. Any suggestions/ideas would be appreciated. Cheers If the merge module is the only thing under its feature, you could create a Set Property custom action to set REMOVE property to that feature name, with condition of PATCH (this would uninstall the feature during the patch). If you went this route a similar custom action for Patch Uninstall may want to set ADDLOCAL to put it back during patch uninstall. Alternatively, you could tweak the merge module (if this is your merge module, that is) to set a negative condition on the components, and set "Reevaluate Condition" flag. ... View more

Mike, I recall that there was an InstallShield update that changed some API that was used on the back-end to read *.ico files. And then this behavior started happening, because it would no longer allow malformed *.ico files (notably *.ico files without the icon file header, and instead using a bitmap header). I would just open up your icon file in a hex editor (or even notepad) and see if it starts with the characters 'BM'. If that is the case, try saving it with an Icon editor, and building again. If this proves to be the issue, I'm not sure when this was fixed. InstallShield Support should be able to track that down for you. Regards, Cary ... View more

scottd72 wrote: BTW Cary, my downloaded installations don't go to c:\Windows\Installer. They all go to C:\Users\ \AppData\Local\Downloaded Installations\ I think I can change it to go under c:\windows\installer - I'm not sure what the best location for them to go is. Actually, they go both places: C:\Windows\installer is the Windows Installer cache. This always get a copy, regardless of operating system, but it's given a random name. And only on Win7 and newer, it's a full MSI copy. "Downloaded Installations" is from a setting on the Setup.exe tab of your InstallShield release. This works too, but only if it's enabled (which it won't necessarily be for every project). You could of course just make sure to enable it for all your projects. Or you can use setup.exe /b like I mentioned, which overrides the default "Downloaded Installations" folder with one of your choosing. ... View more

Roman1 wrote: Not possible. There are ways, actually. But the better question is why do you need to? Development tools generally require Admin rights to do what they need to do--InstallShield is similar in this regard, but I've been assured if you use one of the several ways to make it run non-elevated that it should "mostly work". However, it sounds like you are confusing the fact that the tool needs Admin rights with the idea that the tool's output will require Admin rights. To be clear, projects built by InstallShield are configurable to not require Admin rights. If you test using the 'Test' button of InstallShield, yes, the install will run elevated. However, you should not be doing anything but the most quick-and-dirty of testing on your development machine in any case. Hope this helps. ... View more

scottd72 wrote: I have figured it out. 🙂 If anyone else has a need to get the full .msi file from a self-extracting setup.exe, here is what I found that works best. 1. Run the setup.exe and generate a log file and specify a language code so that the setup will get past the language dialog: setup.exe /L10133 /v"/lv MyLogFile.log" 2. The log file contains the location of the full msi file. Use grep, or some other function to search the log file for the string that starts with "******* Product:" This line contains the path to the msi file that you want. Save the path to a variable. 3. Cancel the installation: taskkill /F /IM msiexec.exe 4. Copy the .msi file to where you want it to go. This seems to be working for me. Is it the best way to do it? Who knows. All I know is that winzip, 7za, winrar and universal extractor do not extract setup.exe's, at least ones built from basic msi projects. Indeed, the setup.exe compression is proprietary. Something that might be somewhat more simple is to just run the install silently on Win7 (MSI 5.0 caches the MSI with internal *.cabs) and use MSI API to find the name of the *.msi under c:\Windows\Installer\ You'll just need the product code to start with, and you'll be able to look it up via MsiGetProductInfo(). Then, you'll need to rename the *.msi to its original name. No process killing, no mess. *Something else I haven't tried myself, but the docs seem to indicate should work: Setup.exe /b"C:\Storage\MyCachedPrograms\" ... View more

JeeCay wrote: You mean as first log e.g. msiexec /I MSIName.msi /log "C:\inst.log"? How to create the second log when using the advertised shortcut? MSI Logging policy: http://support.microsoft.com/kb/223300 ... View more

JeeCay wrote: Hi Cary, thanks for your help. I read about the setup.exe... The point is, the MSI has not been cached. There's only the folder I mentioned before - I already checked for the random named MSI. This is only the second time I'm facing this problem. The first time was caused by an MSI created in Visual Studio (but this MSI was cached locally). I recreated this MSI with InstallShield and everything was fine. So I could do in this case, but perhaps there is a another solution without recreating. Sorry if I didn't specifically address--I just wouldn't expect a prompt for source to come up without a cached *.msi under c:\windows\installer. I would expect an error if MSI couldn't find a cached copy to run from when you invoke a product code that's in the MSI registry. Very strange thing you're seeing. I if you can reproduce this every time, I would suggest posting a log of the first-time install, as well as the second install that prompts for source. That probably will clear things up a bit as to what's happening and why. ... View more