Why doesn't this KB article have example C# code for Managed Code Custom Actions? ... View more

I've had so many issues with installing the VC++ runtime it's not even funny. The registry check will work in all scenarios EXCEPT where you have to install both 32-bit and 64-bit VC++ 2015 runtime on the same machine (because installing the 64-bit runtime adds the registry entry to BOTH sides of the registry, 32-bit and 64-bit locations). In addtion, because MS has made it so difficult to determine when the runtime is installed, many app vendors are choosing to instead bundle the msvcp140.dll with their own installations and COPY it to the system folder (which is technically a violation of the Visual Studio license - but they're doing it anyway). In that scenario, the Flexera provided pre-requisite won't work (because it's keying off finding the correct version of msvcp140.dll). Also keep in mind that VC++ runtime only installs the Microsoft Universal CRT (universal common run time) files if the target system meets the minimum requirements for the UCRT (as described here). I also don't think vc_redist.exe fails when running silently and the UCRT isn't installed. I think your best bet is to determine exactly what runtime files your installation and/or application needs to run (in my case, it's both msvcp140.dll and mfc140u.dll) and then have the pre-requisite get installed if ANY of the files are missing OR if the registry entry is missing. Also make sure you copy the OS checks from the Flexera provided pre-requisite for VC++ 2015 so you know the target system is meeting the minimum requirements for it). I now have 6 separate pre-requites added to my InstallShield project (3 for 32-bit and 3 for 64-bit). One checks for the correct version of msvcp140.dll, one checks for the correct version of mfc140u.dll, and one checks for the registry value. Now the only issue I'm seeing is that the setup prerequisite dialog keeps showing up every now and again despite the fact that I have the "The prerequisite should be hidden from the installation list" option checked for each of the prerequisites. However, this seems to only be happening on Windows Server 2008 (non-R2) systems (so far anyway) so I'm OK with it. ... View more

Hope this saves someone else the trouble I've just gone through to figure this out. Anyway, we had the same problem immediately after releasing our product. It appears that having the pre-requisite key off locating a particular version of "msvcp140.dll" is the problem. After reviewing several customer machines, it appears there are numerous third party applications that are incorrectly (and in violation of the VS 2015 license) copying "msvcp140.dll" directly to the system folder instead of using the redistributable package provided by Microsoft (and run by the InstallShield redistributable). I found several references to using the version specified in the registry location below instead of locating msvcp140.dll. That seems to work for me. This site describes how to fix the pre-req to use the registry key value instead of searching for msvcp140.dll: http://www.firedaemon.com/blog/fixing-installshields-visual-c-2015-runtime-preqrequisite Registry Key (Note 32-bit redistributable will need to key off the location under WOW6432Node on a 64-bit system): Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\vc\Servicing\14.0\RuntimeMinimum Value Name: Version Make sure you check for the correct version based on what version of VS 2015 your application is compiled against. To make matters worse, Microsoft keeps re-releasing the "Update 3" version of the VC++ 2015 runtime and not telling anyone. There have been 3 versions of "Update 3" release so far that I know of: 14.0.24210.0, 14.0.24212.0, and 14.0.24215.1 (the latest as of a few days ago). Check the version of the install file that you are repackaging (vc_redist.x86.exe and/or vc_redist.x64.exe). ... View more

I've tried this on my dev box (Win7 x64) and it seems to be working so far: Copy the last known good version of the problem DLLs (see my previous post) to the "System" folder located under the InstallShield 2010 installation location (ex: "C:\Program Files (x86)\InstallShield\2010\System"). This loads the libraries "side-by-side" in the local InstallShield 2010 install path and seems to be working for me (even after applying the MS KBs known to cause the issue). ... View more

In case anyone else is tracking this issue... The latest KB that breaks IS 2010 is KB 3040272. Uninstalling that KB restored my ability to build projects using IS 2010. After comparing the files updated by the four MS hotfixes that are causing these issues, the four files below are common to all the updates (in System32 and SysWow64). The file versions listed are the versions of the files after I uninstall the updates (last known working version). I don't know for a fact that the updating of these files is what is breaking IS 2010 (this is just a guess). crypt32.dll (6.1.7601.18277) cryptnet.dll (6.1.7601.18205) cryptsvc.dll (6.1.7601.18205) wintrust.dll (6.1.7601.18205) ... View more

I just got back from vacation and my dev box is throwing the error again [64-bit Windows 7 and with IS 2010 (SP1 w/ Hotfix 52410) installed]. Sure enough, 50 new updates were applied by IT while I was gone. Unfortunately, I don't see any of the previously mentioned KB updates (KB 3033929 or KB 3004394 or KB 2949927) applied on my system so this must be a new one. Anyone know which one it is so I can save myself some time? ... View more

I updated my dev box to a new machine, also running 64-bit Windows 7 and with IS 2010 (SP1 w/ Hotfix 52410) installed and after running all the Windows Updates it put update KB 3033929 on the system and I got the same error (6003: "An error occurred streaming ' \MSIEng.isc' into setup.exe" again. So, I can confirm both KB 3033929 and KB 3004394 have this problem. My system doesn't have KB 2949927 installed so I can't attest to that one causing the problem (but have no doubt that it does and will keep an eye out for it). Again, removing the KB and rebooting the system fixes the issue. I REALLY wish InstallShield would update the error 6003 page with this information. 😞 ... View more

Similar problem for me just cropped up. Same error number but my message was: "ISDEV : error -6003: An error occurred streaming '{project_output_path}\MyProject Data\Interm\MSIEng.isc' into setup.exe" Uninstalling Microsoft update KB 3004394 also resolved the issue for me. Some notable differences specific to my issue: I'm using InstallShield 2010 SP1 Basic MSI project with external setup.exe and external CAB files 1 CAB per Feature option enabled I think someone from InstallShield needs to update the general Error 6003 page to let people know about this as it took me a couple of days to figure it out. :mad: ... View more

I opened a support incident with Flexera (SIOC-000144395) for my scenario (error 6258 when building IS 2010 source on Win Server 2012) and, as expected, they told me IS 2010 isn't supported on Win Server 2012 and I would have to upgrade to get support. After upgrading I no longer had this issue. ... View more

We're in the process of trying to set up our build environment on a 64-bit Windows Server 2012 system and are having the exact same problem but with the InstallShield 2010 SP1 Standalone Build module (16.0.0.400). Did anyone ever figure out what's causing this or how to work around it? ... View more

Yes Chris, thanks! Our CM guy is trying to get our build process to work on 64-bit Windows for the first time (finally!) and we had this same issue. The Perl script I wrote was failing to instantiate the IswiAuto16:ISWiProject object. After finding this thread I had him check and, sure enough, the new build system was defaulting to the 64-bit Perl process to run Perl scripts. ... View more

You must set the System.AppUserModel.ID property before you can set any of the other properties. ... View more

Make sure you 1st set the shell property "System.AppUserModel.ID" for the shortcut before you attempt to set any of the other properties ("System.AppUserModel.StartPinOption", "System.AppUserModel.ExcludeFromShowInNewInstall", etc.). ... View more

The shortcuts on that page come from installations that add shortcuts to the [ProgramMenuFolder] location. I _think_ the OS automatically collapes any sub-folders into a single folder. So, if you install the shortcut to "[ProgramMenuFolder]\My Company\My Product\Utilities" the shortcuts would be collected together under a single 'My Company' section on the 'All Apps' page. I also _think_ this is user-specific. IOW, the shortcuts are only installed for whatever user runs the installation (no "All Users" option). The easiest way to control the behavior of the shortcuts is to use an MSI installation and the MsiShortcutProperty table to set the shell properties that allow you to hide the shortcuts on the main Start screen. Unfortunately, I haven't found any examples of doing this using InstallScript or C++ code (which is what I'm trying to do). ... View more

You ever get a solution for this issue? I'm facing the same problem. ... View more