Some observations about InstallScript Suite custom actions

[DLee65]

I have been working with the Suite project and was glad when I learned that I can implement InstallScript custom action to Set and Get Properties.

However, all of that goodness comes with some limitations. Here are some of my early observations.

I am not able to access any of the SYSINFO functions. The code compiles successfully but all functions return zero for a value. I tried to access OSVERSIONINFOEX directly and was not successful here either, but I was not sure how to get the size of the typedef, so I am pretty sure that is why the call to GetVersionExe(&pOSInfo) fails, it requires that the size of the structure be defined before calling.

I am not able to access the LaunchApplication function. It seems to have hooks to sdDialogs and so it fails to even compile.

The good news ... I can access all of the following so far:
1. I can access RegDB functions.
2. I can CreateObject to access VBScript engine. I used it to successfully execute a RegEx on a string and parse out non-alpha characters! I was happy with that.

I will add more observations as I go along and any corrections as I find them. This is for IS2013Premier of course.
The link for information on integrating InstallScript custom actions in IS2013 Premier Suite Projects is found here: http://blogs.flexerasoftware.com/installtalk/suite-installations/

Hopefully some find this helpful.

EDIT: SYSINFO - need to call ISDeterminePlatform ();
Thank you to Mark Manning, a fellow IS guru for finding this for me.
According to help ISDeterminePlatform is normally called by the setup engine during initialization. My guess is that the Suite Engine bypasses this. So if you ever find that you require SYSINFO for a specific InstallScript requirement in a SUITE project custom action, then you must first call ISDeterminePlatform first. Then the SYSINFO data will be populated.

[Roman1]

Hello Dan,

function GetVersionExe does not work also in pure ISScript projects.


The size of a structure you can get using SizeOf:
nSize = SizeOf(pOSInfo); // it is 148, same as using c++ code

[Roman1]

Try this: (it works)

prototype BOOL KERNEL32.GetVersionExA (POINTER );
prototype LONG KERNEL32.WinExec(BYVAL STRING,NUMBER);


OSVERSIONINFO pOSInfo;

nSize = SizeOf(pOSInfo);
pOSInfo.nOSVersionInfoSize = nSize;
nResult = KERNEL32.GetVersionExA(&pOSInfo);

pgm = "C:\\Windows\\notepad.exe";
KERNEL32.WinExec(pgm,1);

[DLee65]

Roman1,

Thank you very much. I should have thought of using SizeOf on the structure.

On a whim, I tried adding back in the ifx.obl and isrt.obl and of course the LaunchApplication and LaunchAppAndWait functions compile correctly. They even function correctly within the Suite project. However, and this is KEY, I cannot predict that it is SAFE to do this under all conditions given Josh's instructions to remove the ifx.obl and isrt.obl files from the Build linker.

Will there be certain conditions that will try to initiate a Sd InstallScript dialog and it will fail?

I cannot predict this. So given Josh's warning to not include the obl files, I have to trust his wisdom in this :D.

BTW, the situation that I find myself in that requires running an EXE in a custom action is that we are 'upgrading' existing customers from SQL Server 2005 Express instance to SQL Server 2012. The 'Upgrade' command line only worked if the existing users were on SP4 of 2005. Not all customers were shipped SP4, many could be still on SP3. So the easier path was to 'Uninstall' the existing instance.

This requires:
1. Looking up the Bootstrap directory for SQL 2005 setup.exe
2. Getting the feature list from the registry for the installed instance and formatting it correctly for the REMOVE= string
3. Then executing the BootstrapPath\setup.exe REMOVE= INSTANCE=

Finding this information is not straightforward either. It involves looking up the InstancePath name in the registry under the Instance Names.

[Roman1]

Dan,

you can call an exe App. pushing a button on Suite Page.

Place an button on a page,
go to Events/Click

Get "open" Action an set e.g. "c:\Windows\Notepad.exe" as document to be open. As verb get "open"
After start you can start Notepad clicking on the new button.

[#6]

I use external DLL function calls in a suite installer successfully. For example, you can OSVERISONINFOEX like this:

    OSVERSIONINFOEX osvi;
    DWORDLONG dwlConditionMask = 0;
    int op=VER_GREATER_EQUAL;

    // Initialize the OSVERSIONINFOEX structure.
    ZeroMemory( &osvi, sizeof(OSVERSIONINFOEX) );
    osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
    osvi.dwMajorVersion = 6;
    osvi.dwMinorVersion = 3;	// 3 indicates 8.1/2012R2

    // Initialize the condition mask.

    VER_SET_CONDITION( dwlConditionMask, VER_MAJORVERSION, op );
    VER_SET_CONDITION( dwlConditionMask, VER_MINORVERSION, op );

    if ( VerifyVersionInfo( &osvi, VER_MAJORVERSION | VER_MINORVERSION, dwlConditionMask) && !IsWow64() )
	{
            // do something
	}

Hope this helps

[joshstechnij]

The link errors from LaunchApplication or similar functions and the SYSINFO initialization issue should be resolved in the next release of InstallShield.

If you need to use LaunchApplication you can add the following code to your script to work around the linker errors:

function number OnLaunchAppAndWaitCallback()
begin
	return LAAW_CALLBACK_RETURN_CONTINUE_TO_WAIT;
end;

function SdShowMsg(szMsg, bShow)
begin
	return ISERR_GEN_FAILURE;
end;

Also, the function LaunchAppAndWaitInitStartupInfo should be called along with ISDeterminePlatform to initialize support for LaunchApplication and SYSINFO. These will be called automatically for suite InstallScript actions in future releases of InstallShield.

Regarding the use of ifx.obl and isrt.obl, these libraries do not contain proper support for suite actions. In addition, they may attempt to use internal objects that are unavailable to InstallScript in suite actions. This could result in crashes or other unpredictable behavior. Isrtsuite.obl is intended as a replacement for these libraries.

[Roman1]

Hello Josh,
Is it possible to call an LaunchApp And Wait function puting them as CA on dialog button? If not, could you implement it for the next version?

[DLee65]

joshstechnij wrote:
The link errors from LaunchApplication or similar functions and the SYSINFO initialization issue should be resolved in the next release of InstallShield.

...
Also, the function LaunchAppAndWaitInitStartupInfo should be called along with ISDeterminePlatform to initialize support for LaunchApplication and SYSINFO. These will be called automatically for suite InstallScript actions in future releases of InstallShield. ...

Josh,
Thank you very much. This is exactly what I needed to help solve not only these problems, but also another problem I was just encountering. I was trying to utilize the ServiceStopService function. It was failing. I checked and double checked my code against help. But based on your comments above I dug deeper and sure enough there is an initialization structure that is required and I almost certain that it is not being called - ServiceInitParams(), for the very same reason as the reason given above.

Hopefully all of these observations help others as they look into implementing InstallScript custom actions with IS 2013 Premier Suite Packages.
I suspect that many of these issues will be resolved with the release of IS 2014 Premier.

Sincerely,
Daniel Lee
Release Engineer, Amazing Charts

[Christopher_Pai]

To all my old friends in this thread... would someone mind emailing me if suite projects ever have managed / C# custom actions in the future? Suite would be very powerful to me if it was all based on WPF and WF.

[joshstechnij]

Roman, it is not currently possible with IS 2013 to call suite actions from the suite UI (such as from a button). This is being looked at for the next release.

Dan, the service parameter initialization will also be resolved for the next release.