Signing the Setup.exe and adding the corresponding certificate is surely the way to ensure the antivirus won't block it, as some antivirus solutions just disable to execution of any unsigned executable. So you might have to sign all your custom-made executables and some other binary files (like hardware drivers, if your setup installs any). But some antivirus solutions might detect your executables as false positive despite the signature and certificate. It all depends on the logic of the antivirus. In that case, you will still need to report the case to the antivirus manufacturer. ... View more

As you pointed out, the SUPPORTDIR variable and the SUPPORTDIR property are not the same. If your DLL is added as Support file in your project, you need to access it with the SUPPORTDIR property. If I remember well, this property is not accessible if your custom action is scheduled for deferred or commit execution, and it returns an empty value if you try to access it in such a custom action. Consequently, you need to pass this property as Custom Action Data. See http://helpnet.installshield.com/installshield21helplib/helplibrary/AccessingProps-DeferredCAs.htm. This page refers to InstallShield 2014, but I'm pretty sure the procedure is the same with 2013. You might also have to add SUPPORTDIR to the SecureCustomProperties property. Good luck! ... View more

Hi Josh, Thanks for your reply. I understood what the root cause was and it was easy to resolve, but you probably understood why I got a bit surprised to see it fail only on Vista. But yes, this error in my code suddenly being revealed might well be related to the new runtime libraries. I would have thought that these libraries would work in the same way on Vista as on other OS's though. Best regards, Reureu ... View more

And did you implement rollback and uninstall custom actions? What about minor upgrades? ... View more

I think MS Report Viewer 2010 exists as prerequisite for InstallShield 2013. Open your project and go to the Application Data-->Redistributables view. It should be listed there. You can add it as prerequisite, and your Setup.exe will launch the installation before installing your MSI package. Or you can add it as feature prerequisite. But I don't think you can add a prerequisite to a patch. ... View more

You probably added some prerequisites without even realizing it. Or InstallShield might have done it for you if you launched a dependency check. ... View more

Welcome to the world of "I'm just replacing a colleague who normally deals with InstallShield"! The funny thing is: if you do a good job, then it becomes your permanent responsibility 😉 If all you want to do is add a file to your Basic MSI project, you can do 2 things: Create a new QuickPatch project. Create a Patch in the "Patch Design" view of your Basic MSI project. Here are a few words about the latter. The idea is to build a new setup that includes all your files (including the new file you want to add). This new setup will have the same product code. The Patch Design allows you to refer the previous version of your setup. It will then create a small package which contains the differences between this previous setup and the new one. As long as you just want to add a file, you can create a patch. The type of changes you can apply through a patch is limited. e.g. you cannot remove a file. Have a look at what you can do in a patch, in a minor upgrade and in a major upgrade: http://helpnet.flexerasoftware.com/installshield21helplib/helplibrary/MajorMinorSmall.htm Once you have built both the new package and the patch, You can then give the full new package to the customers who want to install your new version from scratch. You can give the patch to the customer who already installed the previous version of your product. ... View more

Just changing the product code is not enough to perform a major upgrade. You need to add a Major Upgrade item in the "Upgrades" view of your project. Here are a couple of links that should point you in the right direction: http://helpnet.flexerasoftware.com/installshield21helplib/helplibrary/CreatingMajorUpgrades.htm http://helpnet.flexerasoftware.com/installshield21helplib/helplibrary/Upgrades.htm ... View more

You forgot to mention a few details to allow other people to understand your problem. Project type you are working on? Type of Upgrade you are trying to perform? I assume you are trying to perform a Minor Upgrade, and that your project is Basic MSI. Anyway, you cannot remove or rename components/files between your 2 versions if you want to perform a minor upgrade. You need to follow the rules listed here: http://helpnet.flexerasoftware.com/installshield21helplib/helplibrary/MajorMinorSmall.htm Alternative: go for a major upgrade. ... View more

In theory, you could add some items to the Component and File tables at runtime, so you could benefit from the install/uninstall/rollback mechanism. It would also allow to use the existing version check mechanism (think about the minor upgrade scenario: the files with the highest version wins). Not sure how that would work with file checksums, but it could be worth a try. ... View more

So, what you want to do is add a file to the CD after your installation package is built, and copy it to a target folder during installation? It is not impossible, but you will inevitably face quite a few limitations: [LIST=1] You cannot include a file to an MSI package before this file actually exists. Consequently, you cannot add a file to an MSI package after this package was built. You could possibly use a Transform file, but that's a different story. I don't think you can change an existing file in the source folder after building the MSI package either. I think the MSI package contains quite a few checksum to make sure that the source files are intact. You might also face an issue with the package size. The capacity of a CD is limited, and InstallShield will spread your files (or your cabinet file) on several CD's if the overall size of the package exceeds the size of a CD. So adding files to a CD after the package has been built is not a good idea, even if these files are just "advanced support files". The best way to handle this would be to build your package once all the files (including your user manual) have been produced, and adapt your development process accordingly. In other words: get your technical writers to finish their job earlier. If you really want to supply a user manual that can change until the last minute, you should consider uploading it to a website that your customers can access. However, if you are not able to adapt your development process to these good practice, here is an idea: Do not create any component in your installation package for this file. Now let's assume you have just copied this file to a subfolder of your CD. Create a custom action that just copies this file from one subfolder of the CD to the target directory. You need to create a similar action that removes this file from the target folder on uninstall. Also, don't forget the rollback actions! This idea will not overcome problem no3 listed above, though. Another possibility would consist of building a patch that simply adds your user manual to your product. You would obviously build this patch AFTER building the main installation package. Push this reasoning further, and create a separate installation package for your user manual, then chain both installations. Any other idea? A transform file, maybe? But honestly, your life would be easier if you had all files before building your package. ... View more

Hi there, There was an interesting forum discussion about continuous integration a few weeks ago. http://community.flexerasoftware.com/showthread.php?218792 I mentioned that I don't like the InstallShield integration in Visual Studio. Well, you have just found one of the reason why I don't like it. The InstallShield integration in MSBuild is another thing, and it is working quite well. Here is what I do: I create my Installation project in InstallShield, and I make sure it builds correctly in InstallShield. The meaning of "correctly" here is up to you, but I would expect the have an complete installation package, that includes the prerequisites, and all the required dependencies. By the way, I handle most dependencies by hand in InstallShield, which sort of corresponds to what you described in your previous post. The difference is: You do in in VS, I do it in IS. Then I create a separate VS solution and add my InstallShield project to this solution. This creates the ISPROJ file. One of the reason for isolating the Installation project in its own solution is: we only got a few InstallShield licenses for some developers, and quite a few InstallShield Standalone Build license for our build servers. Therefore, only the build servers and the developers with an InstallShield license build this solution. I normally tweak this ISPROJ file a bit, mainly to override some path variables and some properties, like the ProductName and ProductVersion. In our build system, these properties are set in the Build definition in TFS. I build this solution with MSBuild, and check that the results corresponds to what I built in InstallShield. Once this is done, chances are that the central build of this solution works. What I don't do is: Edit or build my InstallShield project from Visual Studio. It means I cannot just refer the output of another project in Visual Studio, but after a few tests, I realized that the VS integration was changing my ISM file in unexpected ways. To conclude: What counts is the build we create with MSBuild. I don't mind not building my Installation Package in Visual Studio. The Build server does not normally use devenv.exe (aka Visual Studio) to build your package, it uses MSBuild. ... View more

If I were you, I would remove any reference to InstallShield.Tasks.dll. This file is not present if InstallShield is not installed. It is also a good practice to define the "Clean" target in your NoInstallShield.targets. This allows to call MSBuild with the "Rebuild" target. This leads to the following NoInstallShield.targets: I would also place this NoInstallShield.targets file in the same folder as the ISPROJ, and check it in under source control, otherwise, you will need to copy it manually on every developer's machine. But that's only my humble opinion. ... View more

Even better! I didn't even know about this MSBuild property! ... View more