I'm not 100% sure, but I don't think that MSBuild is resolving the value you're passing on the command line. So while you think of it as a variable reference, it's probably being treated as a literal dollar sign, parenthesis, and name. ... View more

The fixes will be included in any future release. The next likely release would be a service pack to IS 2015, but I don't have a time frame at this point. Hopefully applying the hot fix isn't too much of a hurdle for you. 😮 ... View more

We have released a hot fix that should resolve this issue. Officially it's only available for InstallShield 2015, and thus is only supported there, but in practice the DLL in question can be substituted into most earlier versions of InstallShield that have the same DLL. ... View more

We have released a hot fix that should resolve this issue. Officially it's only available for InstallShield 2015, and thus is only supported there, but in practice the DLL in question can be substituted into most earlier versions of InstallShield that have the same DLL. ... View more

Shortcuts are installed into directory entries, so you can definitely modify their location as long as their identifier is in ALL CAPS. But you're right, the trick is knowing when you need to do so. I'd probably suggest dodging that, and just doing this on Windows 8.1 and up (i.e. VersionNT >= 603), unless it clearly makes things worse on Windows 8.1. The only option I can recommend for detecting Windows 10 in an .msi project is to include it in a Suite/Advanced UI or Advanced UI project, and pass a custom property on the command line, e.g. [FONT=Courier New]ISVERSIONNT=[@Platform.FullVersion][/FONT]. Once you've done this, you can reference the ISVERSIONNT property where you would normally reference VersionNT. However note that this approach requires launching your installation from the suite exe, not the raw .msi file; if there is any chance that it will be run without the launcher, you may need to handle the ISVERSIONNT property being empty. ... View more

This behavior is determined by Windows, and this sounds like it mirrors the behavior in the Windows 8 and 8.1 start screen. My only suggestions at this point are to either limit the number of shortcuts that you install, or consider installing them in multiple top-level folders. I haven't tried the latter yet, but given carefully selected folder names, it seems like it could do the trick. I'd love to see other ideas on how to handle this for applications that legitimately have more than a couple shortcuts. ... View more

Oh, I think I took the wrong picture of the use case. I was thinking something like InstallShield has, where each version of InstallShield installs a single registry branch with a version number in it. Or maybe a slight variant of that where it's a slightly different version number depending on something else, but only one at a time. Is your case instead that you need to install several similar branches from one installation, and the number of such branches continually increases over time? I don't have a great answer for that, and totally understand that script seems like an attractive approach. Just bear in mind that component rules are pretty picky about this sort of modification, so, if you stick with the view and need to support minor upgrades, be careful to create new components as appropriate. ... View more

There are a couple layers of nuance here. One is that Windows Installer custom actions typically only get to use a single DLL. Our Managed Code support can actually support a couple more if you modify the ISClrWrap table entries accordingly. Alternately you can put all your files in the support files view and reference them there. However you then get to the next layer of nuance: the selected locale may not match the user setting. Thus the standard localization approach, wherein the language is automatically selected, may not work. So you might have to reference the ProductLanguage property and change your current thread locale accordingly. If you're using an InstallScript project instead of a Basic MSI project, you'll definitely want to use the support files view, and instead of ProductLanguage you can reference SELECTED_LANGUAGE. ... View more

It sounds like you're looking for the right combination of the ISReleaseFlags including x64 and VersionNT64 not being set. If you work out the correct Conditional Statement Syntax for that, you should be able to create a Launch Condition reflecting that. ... View more

Correct; the bit from the help that you mention only applies when a package is marked shared in all suites that have installed it, or may be about to install it, on a given machine. Since IS 2014 didn't have the option to mark a package as shared, that's not the scenario you are in. For that matter, the shared package option in general only works cleanly when all things that deliver it use the same sharing mechanism. In practice, this means that it should always use an IS 2015 or later suite, and always (or never) mark it shared. What happens when you cross this line? If you are matching or upgrading a non-shared or pre-IS2015 package into a shared IS2015 package, it should mostly work; however, the sharing side may never remove the package as it cannot tell when the non-shared reference such as a IS2014 suite is removed. In contrast, the non-sharing side (the IS 2014 suite) will do whatever it did before, including possibly removing the package before the sharing side (IS 2015 suite) has been removed. We'll need to see how this plays out more in practice, but our current hunch is that such packages should typically remain as prerequisite-style dependency packages (i.e. they have no Remove operation). The downside to this approach is that it doesn't offer a good path towards enabling sharing. If I'm reading correctly, the case you describe has a second twist. Not only are you upgrading InstallShield and trying to turn on package sharing, but the newly shared package would skip installing because it's a downgrade from its non-shared predecessor. Instead of skipping installation and tracking shared counts, it fails the install; is that correct? Just to be sure, it has the same package GUID, right? We'll have to think this through a bit more; it's possible that there's something we need to do to make this scenario better. (Although it will never be quite as a clean as a pure sharing scenario.) ... View more

Per VersionNT and VersionNT64, the value should be MajorVersion * 100 + MinorVersion which would calculate out to 1000. However on every preview build of Windows 10 that I've seen, the value is still the same value seen on Windows 8.1: 603; see this technet thread for external confirmation. ... View more

I'm not sure about the specifics of this prerequisite, but it's possible that the .prq file used in the downloaded case has been updated on our servers. If there was a mistake in the original, this could result in the non-download (i.e. the original) failing to install when it should, and the downloading one using corrected information. Try editing the prerequisite to find its download URL (Properties tab, Alternate download location), and see if the prerequisite at that URL differs from the one on your machine. ... View more

There are differences between what you can run at a command prompt, and what you can run through the API CreateProcess. Custom actions in Windows Installer use the latter, and it doesn't support redirection or the commands built into cmd.exe (like dir) that are not executables. Sometimes you can call cmd.exe to do your dirty work, for example, set up your package to run: [SystemFolder]cmd.exe /c "dir > 123.txt" ... View more

I will have to double-check with the engineer that implemented this, but my recollection is that we tested the ability to verify SHA-256 signatures and (according to my fuzzy memory) it worked down through Windows XP, er Windows Vista. Since the API required to place additional signatures requires Windows 7 er Windows 8 (we only require Vista for the IDE), and everything seemed to work without it, we chose to use a single signature whose digest's hash algorithm matches the certificate's hash algorithm. Have you encountered a scenario where this fails? ... View more