InstallShield

Hello,

I have installed InstallShield 2026R1 on a Windows Server 2016 with VisualStudio 2015. There is already an InstallShield 2015 LE installed with a broken license. If I start the application it happens nothing. There is only an application log in Windows Event-Log:

Faulting application name: isdev.exe, version: 32.0.0.68, time stamp: 0x6a486a53

Faulting module name: KERNELBASE.dll, version: 10.0.14393.9140, time stamp: 0x69fb5476

Exception code: 0x80000003

Fault offset: 0x001548c2

Faulting process id: 0x1e8

Faulting application start time: 0x01dd41e55e3226c4

Faulting application path: C:\Program Files (x86)\InstallShield\2026\system\isdev.exe

Faulting module path: C:\Windows\System32\KERNELBASE.dll

Report Id: 324d2af8-a048-4390-acae-8c928a43b830

Faulting package full name: 

Faulting package-relative application ID: 

As long it is the very first start-up after the installation, I would expect that a dialog would popup to ask for the license. But nothing happens.

It would be nice if someone could help me with that problem.

Br,

misterjo

We are using InstallShield 2025 R2 to create a Basic MSI project.

We created a custom action by selecting the following option in the Custom Action Wizard:

Call a public method in a managed assembly

The managed assembly is stored in the Binary table.

We expected this custom action to use the .NET Framework CLR. However, a crash dump captured during execution indicates that the InstallShield-generated custom action wrapper is attempting to start the .NET 8 CoreCLR runtime.

The relevant call stack is as follows:

Ijwhost!start_runtime_and_get_target_address Ijwhost!start_runtime_thunk_stub CoreClrNativeHelper!CallCoreMethod MSI278F+0x3018 msi!CallCustomDllEntrypoint

The dump also contains the following module information:

IMAGE_NAME: Ijwhost.dll IMAGE_VERSION: 8.0.1825.31117 OSPLATFORM_TYPE: x86

Based on this information, it appears that the InstallShield-generated wrapper is using the 32-bit .NET 8 CoreCLR runtime rather than the .NET Framework 4.x CLR.

We would like to execute the custom action assembly using .NET Framework 4.8 instead of .NET 8.

Does anyone know whether this is the expected behavior in InstallShield 2025 R2?

We would also appreciate any information regarding the following questions:

1. Does the "Call a public method in a managed assembly" custom action type use .NET 8 CoreCLR internally in InstallShield 2025 R2?
2. Has the runtime host for this custom action type been changed from the .NET Framework CLR to the .NET 8 CoreCLR?
3. Is there a project setting, custom action setting, or other configuration that allows this custom action to use .NET Framework 4.8?
4. Is the IS_CLR_VERSION property still applicable to this type of custom action in InstallShield 2025 R2?
5. If IS_CLR_VERSION is applicable, would setting it to v4.0.30319 cause the custom action to use the .NET Framework 4.x CLR?
6. Are the .NET Framework-based managed custom action and the .NET Core-based managed custom action separate custom action types in InstallShield 2025 R2?
7. If they are separate custom action types, how can the .NET Framework-based type be explicitly selected in the InstallShield user interface?
8. Is there any official documentation, release note, or migration guide that describes this runtime behavior or a related specification change?

For reference, the custom action assembly is intended to target .NET Framework 4.8.

If anyone has encountered the same behavior or knows the supported method for executing a .NET Framework 4.8 assembly as a managed custom action in InstallShield 2025 R2, any advice would be greatly appreciated.

Screenshots of the custom action configuration and the crash dump analysis results are attached.

Currently, we use a small utility that makes use of Windows scripts to embed language transforms into our .msi package. The scripts are wilanguid and wisubstg.vbs. So, once embeded, the install can be called like this to show the different languages....

msiexec .i path\to\installer.msi TRANSFORMS=:languageId

The colon indicates that the transform is embedded I believe.

My question is, is there a release option in the InstallShield IDE to automatically embed the transforms as opposed to the need to maintain the external utility?

If not, that would be a fairly nifty option to have I think.

Any help or guidance appreciated.

Thanks in advance!!

I have an InstallShield package that creates an MSI package which typically installs via InTune or msiexec /i package.msi /qn /norestart.

I want to issue a hot fix to the product.

What do I need to change in InstallShield?

I tried just changing the Package Code, but when I test it using msiexec /i package.msi, I get the message "Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel."

If I use the /qn /norestart options, it "succeeds" (%ERRORLEVEL%=0) but nothing has changed.

What do I need to change to make this work?

Hi all,

Just wondering if anyone has a solution to hide the Setup Status text (and a white block) in the installation progress window?

We've recently changed logo, giving us a full width bitmap at the top of the window. However, our installation status window now looks a little messy as 1) we have "Setup Status" appearing into the bitmap as well as 2) an offset bitmap resulting in a strange white block?

Our installer steps look correct (with no white block) and we'd like the installation dialog (with the progress bar) to look the same (as below)

Is there a way to alter the Setup Status dialog?

I've been through the InstallScript but I can't see any place where this dialog is altered by us, though the default bitmap is being set correctly in the script:

szBmpPath=SUPPORTDIR ^ "ourcompany.bmp";

SdInit(); 

DialogSetInfo (DLG_INFO_ALTIMAGE, szBmpPath, TRUE);

Any help appreciated!