For the first part, it sounds like you need to add a property that tracks which feature was already selected. For example, when neither is selected, it could be empty. When one is selected, it could be set to the name of that feature. When both are selected, it could use the value of that property to decide which feature to reset. For the second part, you can reference the FEATURE[name].installState pseudo property. While you could make the conditions really crazy and handle this without extra properties, I think it would be much more understandable to use it once to set up two properties that reflect the desired actionState when they need to be cleared. Then just use those properties as the value for the SetProperty actions. That should mix well with the needs for the first part. ... View more

We have implemented tighter DLL loading restrictions during installations, so the new behavior does not surprise me. For this particular case you can probably work around it most easily by explicitly loading the dependencies in a preceding call to UseDLL. For example: (tweak the order as necessary) UseDLL(SUPPORTDIR ^ "CRYPT.DLL"); UseDLL(SUPPORTDIR ^ "CIPHER.DLL"; UseDLL(SUPPORTDIR ^ "LOGIN.DLL"); You will probably then also want to call UnUseDLL for each of those DLLs where you currently only have it for LOGIN.DLL. ... View more

I'm not certain that your string came through correctly, but it looks like it has an extra left square bracket about 1/3 of the way through: ƒsƒ…[ƒ^‚ If so, you should either remove that square bracket, or escape it as the following sequence: [\[] ... View more

Gotcha. Make sure to be as clear as you can what sort of customizations you want to be possible. 🙂 As a side comment, if you can possibly wait until the regular package install phase, I would strongly suggest installing .NET as a package rather than as part of an Event/Action. This may not be feasible if you need to use .NET earlier than when the packages are installed, but the Suite/Advanced UI project is designed around installing packages as part of the package phase. ... View more

If you haven't already gotten your hands on at least version 23.0.0.290 of ISWIBuild.dll (download), give that a try (back up and then replace the ISWIBuild.dll in your InstallShield System folder with this one). It fixes some potential errors, and clears up some remaining confusion in the error messages when there is more than one localizable string column in a table. In this case, both Name and Value of ISXmlElementAttrib are localizable, so this is likely to be relevant. Looking at the categories for the fields in the ISXml* tables, however, I don't see any string validation issues that I would expect to arise. So until we're certain exactly what string is causing problems, I'm going to have to fall back to some general guidance here. The quoted value you show looks fine: it has a few property references, but both UG_WEBAPI_PROTOCOL and UG_WEBAPI_FQDN look perfectly valid. In the screenshot I see reference to a string include add[ ] where that stuff is not a valid property reference. If somehow this is being validated as Formatted text, the square brackets that are around things other than property references would need to be escaped - that is, replaced with [\[] and [\]] respectively. Keep this in mind as a possibility; hopefully the updated ISWIBuild.dll will make more sense of things. ... View more

The "correct" approach is probably either to create a transform that swaps out the file, or to refactor your setup such that the file is handled in some other way (perhaps as an auxiliary install, perhaps as a DuplicateFile and RemoveFile entry, perhaps something else). In general all files are either known by version (if they're an exe/dll/etc. file with a version block), or by file hash. Since XML files do not have PE version blocks, it will be hashed. I forget if mismatched hashes affect first-time installs, but they definitely have an impact on repairs, minor upgrades, and patching scenarios. ... View more

Currently the new loading screen for Suite/Advanced UI installations is not configurable other than the icon you choose for setup.exe, which is then drawn on a white background window with a progress bar. If you'd like to request the ability to configure this part of the experience, it would help to submit a request through your support contact, but we can certainly take note of it here. Are you specifically trying to alter the appearance, and when that was not possible, you examined trying to disable it instead? ... View more

The Express edition does not have support for editing already-built MSI files, or for editing projects that have been edited in the Professional or Premier editions. If you need to edit one of those, consider evaluating the Professional or Premier edition instead of the Express edition. ... View more

I think the problem with *.json is that it's a long file name; the WildCardFilename category requires a value that's compatible with short file names, and thus a short|long dual-value if you need to use a long file name. For example: *.jso|*.json. I'm not sure if there's anything wrong with "error.log". You should be able to work around the issue by editing the string value in either the String Editor, or in the RemoveFile table of the Direct Editor. We're tracking this RemoveFile behavior as IOJ-1774046. ... View more

Great, glad you got things working! And I totally agree. While uninstall shortcuts are discouraged since Windows Vista (or earlier), we should ensure that InstallShield isn't causing extra errors in your project. We'll look into it. ... View more

Hmm, yeah, string IDs aren't directly accessible in Express; we could certainly clean up the error message for this case. This error means that the value of one of your shortcut's names is invalid according to MSI rules. (We previously weren't enforcing this correctly.) You should be able to find the bad name by looking in the Shortcuts view, and testing each of your shortcuts. For example, change the name to something else, build, and then change it back. Let me know if that's not enough to get you going. Once we know the problematic value, I can make more specific recommendations. ... View more

We have fixed this for InstallShield 2016. We had to rework things internally, so we were unable to address it in InstallShield 2014. ... View more

This is being tracked as issue IOJ-1744694. Unfortunately there are no great workarounds in a suite installation with multiple-languages; the only solution I know in InstallShield 2015 is to make single-language installations. However it has been fixed in InstallShield 2016. ... View more

We've enhanced click events in InstallShield 2016 to support running actions before closing a secondary window. While there might be some esoteric workarounds available before that (I haven't found one), it should be straightforward in InstallShield 2016 with the new Close Window event. ... View more

See MsiNTProductType. ... View more