InstallShield

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!!

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!

When I create a web MSI for IIS (Basic MSI), the folder does not install into the wwwroot directory.

In the General Information section, the INSTALLDIR variable is correctly set to "[IISROOTFOLDER]MyWebSite".

In the Internet Information Services view, under Web Sites, the "Content Source Path [Local or UNC]" property contains the variable "[INSTALLDIR]".

And in System Search, IISROOTFOLDER is correctly retrieved from the registry key "HKLM\SOFTWARE\Microsoft\InetStp\PathWWWRoot". The MinorVersion and MajorVersion variables are also being retrieved.

Am I missing something?

I am using InstallShield 2025 R1 Premier Edition.

I also tried using IISScan.exe to retrieve information about a website, but it returns the error: "The website 'MyWebSite' was not found."

Is there a fix for broken hyperlinks in build error codes? 

Example: Error code  -6090 = https://community.flexera.com/t5/forums/searchpage/tab/message?filter=includeTkbs,location&q=%22-6090%22&include_tkbs=true&location=board:InstallShield-Knowledge&collapse_discussion=true

At work we handle moved API pages by adding redirects instead of just letting the links break.