About Barbara

Barbara · ‎Jul 10, 2014

I use a tool written in C# which manages the build of my Install Shield Projects by using IS 2012 the automation interface. The tool checks aut the ISM-projects, increases the version number , builds, checks in and so on. Now I am using a TFS build server with different build agents. Is it possible to use the tool to build concurrent setups on the different build agents? This would speed up the build process, because the setup build time is the factor which determines the overall build time. In the past I often had locks when trying to build concurrent setups on the same machine. Has anybody experiences in doing this? Best regards Barbara

Barbara · ‎Oct 10, 2013

I use the following registry key to check for Framework 4.5: HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full, you can check for the entries Release and Version. Barbara

Barbara · ‎Oct 10, 2013

If there are entries left at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services then check, if the service is correctly uninstalled. Look in the setup log of your software removal. Can you see the service name in the service applet? The entries in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\services are copies of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services entries, which are used for the "last known good". Which operating system are you using? Barbara

Barbara · ‎Oct 10, 2013

In my opinion there is no way to do this: If you have one component marked as 64bit, then the whole setup has to be a x64 installation. I also tried a lot with "mixed installations" and ended with two setups, one for the 32bit and one for the 64bit world. With InstallScript you can write from a 32bit installation to the 64bit part of the registry key, but you cannot change the installation directories of your files from the 32bit to the 64bit location. Barbara

Barbara · ‎Jun 26, 2013

I also use the redemption.dll in some of my installation packages. I never had the problems you describe. I install the file in the following way: The setup must be started as administrator. The installation is always done per machine, not per user. The redemption.dll is installed in [CommonFilesFolder]\SubDirectory During the build of the setup I use the COM extract at build flag for the component containing the redemption.dll. If I look in the MSI-Package, I can see that the entries for the redemption.dll are written to HKEY_CLASSES_ROOT. Hope this helps Barbara

Barbara · ‎Jun 26, 2013

You can make your own prq-File to install the Framework 4.5. Or you download and install the newest Test-version of InstallShield2013. After installation you will find the updated prq-files on your computer, which you can also use with older version of InstallShield. Barbara

Barbara · ‎Jun 26, 2013

Check the settings of the installationpackage of the newer product. What do you want to install: A major or minor update? Which parameters did you change compared to the older package; ProductVersion, ProductName, PackageCode, ProductCode, UpgradeCode? Did you populate the UpgradeTable? The behavior of the update package relies on the parameters which you have changed compared to the installed product. Barbara

Barbara · ‎Jun 26, 2013

I installed a evaluation version of InstallShield2013 on a Windows7 x64 VMWare. I converted a InstallShield2009 project and tried to build it. During the build InstallShield2013 crashes with the following entries in the EventViewer: Faulting application name: isdev.exe, version: 20.0.0.376, time stamp: 0x51a6dde3 Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace5b9 Exception code: 0x40000015 Fault offset: 0x0005beae Faulting process id: 0x648 Faulting application start time: 0x01ce72491346dc9c Faulting application path: C:\Program Files (x86)\InstallShield\2013\system\isdev.exe Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll Report Id: 416c2b03-de47-11e2-a2bc-000c29e8dd03 Whats the reason ? Should I install a specific VS Runtime package? Thank you for your help Barbara

Barbara · ‎Jun 19, 2013

InstallShield 2012 crashes sometimes during the build on my development machine: Windows 7 Enterprise, 32bit, run in a VMWare virtual machine. In the event viewer I can see the following error;: Name der fehlerhaften Anwendung: isdev.exe, Version: 18.0.0.329, Zeitstempel: 0x4e51e7d1 Name des fehlerhaften Moduls: MSVCR90.dll, Version: 9.0.30729.6161, Zeitstempel: 0x4dace5b9 Ausnahmecode: 0x40000015 Fehleroffset: 0x0005beae ID des fehlerhaften Prozesses: 0xb74 Startzeit der fehlerhaften Anwendung: 0x01ce66768f0b7b8b Pfad der fehlerhaften Anwendung: C:\Program Files\InstallShield\2012\System\isdev.exe Pfad des fehlerhaften Moduls: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll Berichtskennung: 5b5943ee-d8e3-11e2-8e51-000c29a8a057 All the Microsoft Updates are installed. Does InstallShield need a special VC90 runtime version? Thank you for your help Barbara

Barbara · ‎Mar 22, 2013

You should author a major upgrade and schedule the RemoveExisting products action in the correct place. Barbara

Barbara · ‎Feb 22, 2013

It is not completely clear to me what you want to do. As I understand it, you give some properties through the command line and wonder if they are evaluated or not, is this right? If this is the problem you can write a verbose MSI Log file and look in this, if your properties are set correctly. Use a commandline like: Setup.exe /v"/L*v c:\test.log "MYPROPERTY1=value1" You will write a MSI-logfile to c:\test.log Barbara

Barbara · ‎Feb 19, 2013

Edward, this is looking really strange for me. The only things I can think of are: Is the property SUPPORTDIR accidently set in the Property Manager to a value of 0 ? If so, delete the entry. Also look in the Property Manager for the value of the property SecureCustomProperties: Is the property SUPPORTDIR included ? Barbara

Barbara · ‎Feb 18, 2013

I always use the language independent supportdir and it is always working. So I would suggest the following to you: Please write a verbose MSI logfile and see how the supportdir is created. In my logfile I can see something like: [CODE]Aktion gestartet um 13:54:06: ISSetupFilesExtract. MSI (c) (D8:F8) [13:54:06:677]: Invoking remote custom action. DLL: C:\Users\ADMINI~1\AppData\Local\Temp\MSI824D.tmp, Entrypoint: SFStartupEx MSI (c) (D8:10) [13:54:06:677]: Cloaking enabled. MSI (c) (D8:10) [13:54:06:677]: Attempting to enable all disabled privileges before calling Install on Server MSI (c) (D8:10) [13:54:06:677]: Connected to service for CA interface. 1: Starting to extract setup files 1: Getting SUPPORTDIR property : 1: Extracting SetupFiles to: C:\Users\ADMINI~1\AppData\Local\Temp\{63A4B861-E466-41D4-9FD6-CF7F4F697FDB} 1: Getting ISSetupFile table view [/CODE] Look at the end of your logfile: How is the SUPPORTDIR property set? How do you retrieve the SUPPORTDIR property: Do you use a deferred CA? If yes, you have to use a CA type 51 to set the property for the deferred execution. Barbara

Barbara · ‎Jan 25, 2013

Maybe I found the solution: On all 64bit computers the UAC was turned off, on all 32bit computers the UAC was turned on. This led to the different behavior. I added the properties SETUPEXEDIR and SETUPEXENAME to the Property SecureCustomProperties and it seem to work (but further testing needed). But: Can somebody from InstallShield explain me this behavior? Best regards Barbara

Barbara · ‎Jan 25, 2013

I have a product for which I have a 32bit and a 64bit Installer. Operating system for the installation is in both cases Windows 7. For both setups I use Feature Prerequisites to install the VC++ 2010 SP1 redistributable. As I learned this is done by a custom action called ISInstallPrerequisites. This CA checks the value of the properties SETUPEXEDIR and SETUPEXENAME which are set when starting the setup.exe. This behavior seems to be different with 32bit or 64bit setups. In both cases I can see in the logfile, that the properties SETUPEXEDIR and SETUPNAME are set to the correct values, but ISInstallPrerequisites seems to behave different: 64bit Snippets of the logfile: MSI (c) (8C:64) [09:34:34:455]: PROPERTY CHANGE: Adding SETUPEXEDIR property. Its value is 'C:\Users\sam\AppData\Local\Temp\rl4egnod.tfb\Proom_x64'. MSI (c) (8C:64) [09:34:52:664]: Doing action: ISInstallPrerequisites Aktion 09:34:52: ISInstallPrerequisites. Aktion gestartet um 09:34:52: ISInstallPrerequisites.MSI (c) (8C:B4) [09:34:52:706]: Invoking remote custom action. DLL: C:\Users\sam\AppData\Local\Temp\MSIDAF4.tmp, Entrypoint: InstallPrerequisites InstallShield 09:34:52: Features with associated prerequisites are being installed or advertised. Finding setup.exe... InstallShield 09:34:52: Looking for setup launcher in 'C:\Users\sam\AppData\Local\Temp\rl4egnod.tfb\Proom_x64' with name 'setup.exe'... InstallShield 09:34:52: Checking for correct setup launcher 'C:\Users\sam\AppData\Local\Temp\rl4egnod.tfb\Proom_x64\setup.exe'... InstallShield 09:34:52: Found matching product code in 'C:\Users\sam\AppData\Local\Temp\rl4egnod.tfb\Proom_x64\setup.ini'. The bevore set properties SETUPEXEDIR and SETUPEXE are evaluated and the installation can continue. 32bit Snippets of the logfile: MSI (c) (F8:88) [09:26:06:050]: PROPERTY CHANGE: Adding MsiLogFileLocation property. Its value is 'C:\Users\VW34E5~1.PRO\AppData\Local\Temp\Proom_2.1_install.log'. MSI (c) (F8:88) [09:26:06:050]: Command Line: REINSTALL=ALL REINSTALLMODE=vomus IS_MINOR_UPGRADE=1 TRANSFORMS=1031.MST SETUPEXEDIR=C:\Users\vw.PROCAD_KA\AppData\Local\Temp\j4i3yts2.znt\Proom SETUPEXENAME=setup.exe CURRENTDIRECTORY=C:\Program Files\PROCAD\Proom CLIENTUILEVEL=0 CLIENTPROCESSID=5624 MSI (c) (F8:88) [09:26:06:051]: Ignoring disallowed property SETUPEXEDIR MSI (c) (F8:88) [09:26:06:051]: Ignoring disallowed property SETUPEXENAME MSI (c) (F8:88) [09:26:08:271]: Doing action: ISInstallPrerequisites Aktion 09:26:08: ISInstallPrerequisites. Aktion gestartet um 09:26:08: ISInstallPrerequisites. MSI (c) (F8:FC) [09:26:08:320]: Invoking remote custom action. DLL: C:\Users\VW34E5~1.PRO\AppData\Local\Temp\MSI23C6.tmp, Entrypoint: InstallPrerequisites InstallShield 09:26:08: Features with associated prerequisites are being installed or advertised. Finding setup.exe... InstallShield 09:26:08: Checking SourceList directories for setup launcher... InstallShield 09:26:08: Last used source: 'C:\Users\vw.PROCAD_KA\AppData\Local\Temp\Temp1_proom.zip\Proom\' InstallShield 09:26:08: Looking for setup launcher in 'C:\Users\vw.PROCAD_KA\AppData\Local\Temp\Temp1_proom.zip\Proom\' with name 'setup.exe'... InstallShield 09:26:08: Next source: 'C:\Users\vw.PROCAD_KA\AppData\Local\Temp\Temp1_proom.zip\Proom\' InstallShield 09:26:08: Asking user to provide setup launcher location... The property SETUPEXEDIR is not evaluated, and the installation cannot continue. The 32bit log led me to the opinion, that the properties should be entered in the SecureCustomProperties Property, but I think it makes no sense, because the installation actions for the prerequisites are not executed deffered. Also in both cases (32bit and 64bit) they are not entered in SecureCustomProperties. Or could it be a problem with UAC? Any other hints? Best regards Barbara

Online Status	Offline
Date Last Visited	‎Mar 18, 2019 12:10 PM

Run concurrent Builds with IS automation interface on a TFS build server

Registry Key

check if the service is correctly uninstalled

There is no way to do this

COM extract at build ?

Download newer test version or make your own prq-file

check your update setings

isdev.exe crashes during build

InstallShield2012 crashes sometimes during a build

RemoveExistingProducts action

Verbose MSI log ?

Property already set in Property Manager?

Supportdir

SecureCustomProperties

Problems with FeaturePrerequisites during minor update