This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: SUITE: Can a C# custom action set and get properties
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 22, 2014
06:14 AM
SUITE: Can a C# custom action set and get properties
There is documentation on how to set and get properties for a C++ DLL for a Suite Project.
There is documentation on how to set and get properties for a PowerShell script for a Suite Project
But I have not found any documentation if it is possible to Set and Get properties for a Suite Project.
The reason I ask is that I am not a C++ developer, and need to write a custom action to determine if our SQL Server Instance is installed and if installed, if it is Express version, and what version it is. This is too complex for a simple registry lookup in the events and requires a custom action to complete.
I can code this with C#, but I cannot find documentation on how to Set and Get properties and interface with the Suite UI using C#. There is good documentation on how to do this with C++.
Is this possible with C#?
I have tried to get answers from Flexera Support but I am running in to communication barriers with their support and just getting answers like Yes, you can insert a C# custom action into your Suite Project, which is not what I asked them. I wonder if their support is outsourced or overseas now, because I have to continually have to re-explain myself to them?
So I have come here to the forums in hope of getting a real answer that Support cannot provide in a timely manner. *sigh*
Ty to anyone who can provide any direction and possible code fragments for C#.
Respectfully,
Daniel Lee
Release Engineer, Amazing Charts
There is documentation on how to set and get properties for a PowerShell script for a Suite Project
But I have not found any documentation if it is possible to Set and Get properties for a Suite Project.
The reason I ask is that I am not a C++ developer, and need to write a custom action to determine if our SQL Server Instance is installed and if installed, if it is Express version, and what version it is. This is too complex for a simple registry lookup in the events and requires a custom action to complete.
I can code this with C#, but I cannot find documentation on how to Set and Get properties and interface with the Suite UI using C#. There is good documentation on how to do this with C++.
Is this possible with C#?
I have tried to get answers from Flexera Support but I am running in to communication barriers with their support and just getting answers like Yes, you can insert a C# custom action into your Suite Project, which is not what I asked them. I wonder if their support is outsourced or overseas now, because I have to continually have to re-explain myself to them?
So I have come here to the forums in hope of getting a real answer that Support cannot provide in a timely manner. *sigh*
Ty to anyone who can provide any direction and possible code fragments for C#.
Respectfully,
Daniel Lee
Release Engineer, Amazing Charts
(12) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 22, 2014
01:41 PM
Daniel,
I don't know about C#, but when we need to validate the SQL connection on our dialog, we test it with an ADODB.Connection object using InstallScript. That would require a SQL login/pwd (or Windows login) though. If the connection is valid, you could do some parsing (SQL or InstallScript) on something like SELECT @@VERSION (again, using the ADODB object in InstallScript) to determine what version the DB engine is.
Don't know if that helps or not.
disclaimer: we use InstallShield Professional and don't have access to Suite features
I don't know about C#, but when we need to validate the SQL connection on our dialog, we test it with an ADODB.Connection object using InstallScript. That would require a SQL login/pwd (or Windows login) though. If the connection is valid, you could do some parsing (SQL or InstallScript) on something like SELECT @@VERSION (again, using the ADODB object in InstallScript) to determine what version the DB engine is.
Don't know if that helps or not.
disclaimer: we use InstallShield Professional and don't have access to Suite features
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 23, 2014
05:57 AM
Thank you for the reply. Unfortunately Suite features do not utilize InstallScript at all.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 23, 2014
12:50 PM
We don't have explicit support for C# or InstallScript today, so feature request noted. I know it happens to be possible to do either, but they are both advanced and unsupported. We do have a blog post in the works about using InstallScript in Suites; what sort of time scale are you on?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 24, 2014
08:02 AM
The blog article that Michael referenced was published yesterday. Here's a link:
Using InstallScript Actions in Suite/Advanced UI Projects
Using InstallScript Actions in Suite/Advanced UI Projects
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 24, 2014
12:35 PM
Thank you for the link to the blog post.
Implementing the code was relatively easy. However, is there a way to debug the code.
The code compiles without any errors but when I execute the code in my debuglog I get a return code of
1-24-2014[01:16:06 PM]: Running event 'IsOsSupported'
1-24-2014[01:16:06 PM]: Launching InstallScript action in function 'IsOSSupported'
1-24-2014[01:16:06 PM]: Engine: request for proxy handler, 0, 0
1-24-2014[01:16:07 PM]: Action returned value 0x80004003
1-24-2014[01:16:07 PM]: Action 'IsOsSupported' returned status 0x80070643
My code simply calls into SYSINFO calls to determine major, minor, servicepack, and productType. Based on this information it will set SuiteSetProperty "OSNAME" and "OSVALUE"
Prototype is:
export prototype BOOL IsOsSupported();
Possibly it does not support the BOOL type?
I realize that this is an early implementation and all I have for documentation is the installtalk post from yesterday.
I tried to debug but as I suspected, it errors out.
I guess I could copy code parts into a real project and test the parts to validate them. But if you know of a better way that would be appreciated.
Sincerely,
Daniel Lee
Release Engineer, Amazing Charts
EDIT: I took and commented out the code within the function. I also removed the bool return type.
So the prototype now looks like the following:
Implementing the code was relatively easy. However, is there a way to debug the code.
The code compiles without any errors but when I execute the code in my debuglog I get a return code of
1-24-2014[01:16:06 PM]: Running event 'IsOsSupported'
1-24-2014[01:16:06 PM]: Launching InstallScript action in function 'IsOSSupported'
1-24-2014[01:16:06 PM]: Engine: request for proxy handler, 0, 0
1-24-2014[01:16:07 PM]: Action returned value 0x80004003
1-24-2014[01:16:07 PM]: Action 'IsOsSupported' returned status 0x80070643
My code simply calls into SYSINFO calls to determine major, minor, servicepack, and productType. Based on this information it will set SuiteSetProperty "OSNAME" and "OSVALUE"
Prototype is:
export prototype BOOL IsOsSupported();
Possibly it does not support the BOOL type?
I realize that this is an early implementation and all I have for documentation is the installtalk post from yesterday.
I tried to debug but as I suspected, it errors out.
I guess I could copy code parts into a real project and test the parts to validate them. But if you know of a better way that would be appreciated.
Sincerely,
Daniel Lee
Release Engineer, Amazing Charts
EDIT: I took and commented out the code within the function. I also removed the bool return type.
So the prototype now looks like the following:
export prototype IsOsSupported();
function IsOsSupported()
NUMBER nOSType, nSP;
STRING strServicePack;
begin
SuiteLogInfo("ACSetupUtility INFO: This is a test. ");
SuiteSetProperty("TESTPROPERTY","TemporaryValue");
end;
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 24, 2014
02:00 PM
The function declaration and prototype needs to match what is in the blog article. Your current code should run without an error by changing it to the following:
Note that the only changes are to the prototype to accept an OBJECT parameter and the function declaration to define a parameter for the OBJECT (this is the suite extension object passed to the script function; the suite wrapper functions such as SuiteLogInfo can be used instead of the object). The return type can optionally be defined as NUMBER to allow for explicitly returning success/abort/failure values (the same as MSI DLL custom actions).
Note that you can debug an InstallScript action in a suite project by launching the suite setup with the following command line options:
/d"C:\Path_To_Script_Debug_Files"
The path to the script debug (.dbg) files is optional if they are accessible in the path the .dbg file was originally created in. For the debugger to launch successfully the suite needs to be launched as an elevated process (such as from an administrator command prompt).
export prototype IsOsSupported(OBJECT);
function IsOsSupported(oExtension)
NUMBER nOSType, nSP;
STRING strServicePack;
begin
SuiteLogInfo("ACSetupUtility INFO: This is a test. ");
SuiteSetProperty("TESTPROPERTY","TemporaryValue");
end;
Note that the only changes are to the prototype to accept an OBJECT parameter and the function declaration to define a parameter for the OBJECT (this is the suite extension object passed to the script function; the suite wrapper functions such as SuiteLogInfo can be used instead of the object). The return type can optionally be defined as NUMBER to allow for explicitly returning success/abort/failure values (the same as MSI DLL custom actions).
Note that you can debug an InstallScript action in a suite project by launching the suite setup with the following command line options:
/d"C:\Path_To_Script_Debug_Files"
The path to the script debug (.dbg) files is optional if they are accessible in the path the .dbg file was originally created in. For the debugger to launch successfully the suite needs to be launched as an elevated process (such as from an administrator command prompt).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 26, 2014
08:34 AM
Josh,
I made the required changes but I am still encountering the same errors.
So I went back to basics and created a new suite project that just attempts to install the orca.msi as a project and tries to run a very basic InstallScript action as an OnBegin event.
I will attach the zip file with the projects here but below is the content of the InstallScript file. I deliberately kept it almost identical to yours, except I am trying to set a property, because that is my goal ultimately, to set properties in the Suite UI in the OnBegin event.
Perhaps I cannot use the #include "ifx.h"?
I do not see this in your example. However, if I remove it the project does not compile successfully and I cannot access normal functions such as RegDBSetDefaultRoot, etc.
In my Suite project I carefully copied in the function name, MyFunction for the
I added in the required files for setup.inx, ISRT.dll, ISSetup.dll, and ISBEW64.exe.
When I execute the application all I get is the following from the debuglog. I am running from a cmd prompt that has administrative rights:
I do not know what this error means. Does it mean that it could not find the engine? Does it mean that my function is malformed? Or is it some other type of error?
UPDATE: I could not upload the project files as the zipped file size was greater than 5MB. I am going to see if I can reduce that size and try again.
UPDATE2: I deleted the compiled Suite file and zipped the files again. Now it will upload. Hopefully you can help give some insight to this problem. Thank you.
UPDATE3: I tried to see if the #include "ifx.h" was the problem. I knew that I still required an #include, so I found that the ISRT.h file has the required header defines for the suite project and also for the registry information. So I commented out the include for the "ifx.h" and added an include for the "ISRT.h" and recompiled. I tested again and get the same error. There are no compile errors however.
QUESTION: I am wondering, since you ask us to remove references to the ifx.obl and isrt.obl; should we be using the #include for the .h files for these as well. Should my version of IS2013 include a script folder for issuite? I am just speculating here based on the pattern I am seeing in the script folder for MSI and based on the request not to use the linker files for ifx and isrt. I do not have a header file for the isrtsuite.h to include for compile that I can find anywhere in the scripts directory.
I made the required changes but I am still encountering the same errors.
So I went back to basics and created a new suite project that just attempts to install the orca.msi as a project and tries to run a very basic InstallScript action as an OnBegin event.
I will attach the zip file with the projects here but below is the content of the InstallScript file. I deliberately kept it almost identical to yours, except I am trying to set a property, because that is my goal ultimately, to set properties in the Suite UI in the OnBegin event.
// Included header files ----------------------------------------------------
#include "ifx.h"
export prototype MyFunction(OBJECT);
function MyFunction(oExtension)
STRING sValue;
begin
sValue = "TRUE";
SuiteSetProperty("RUNSQLSETTING",sValue);
end;
Perhaps I cannot use the #include "ifx.h"?
I do not see this in your example. However, if I remove it the project does not compile successfully and I cannot access normal functions such as RegDBSetDefaultRoot, etc.
In my Suite project I carefully copied in the function name, MyFunction for the
I added in the required files for setup.inx, ISRT.dll, ISSetup.dll, and ISBEW64.exe.
When I execute the application all I get is the following from the debuglog. I am running from a cmd prompt that has administrative rights:
1-26-2014[09:08:37 AM]: Running event 'TestActionOnBegin'
1-26-2014[09:08:37 AM]: Launching InstallScript action in function 'MyFunction'
1-26-2014[09:08:37 AM]: Engine: request for proxy handler, 0, 0
1-26-2014[09:08:39 AM]: Action returned value 0x80004003
1-26-2014[09:08:39 AM]: Action 'TestActionOnBegin' returned status 0x80070643
1-26-2014[09:08:39 AM]: UI DLL: Shutting down
1-26-2014[09:08:39 AM]: Original exit status: 0x80070643, final exit status: 0x00000643
I do not know what this error means. Does it mean that it could not find the engine? Does it mean that my function is malformed? Or is it some other type of error?
UPDATE: I could not upload the project files as the zipped file size was greater than 5MB. I am going to see if I can reduce that size and try again.
UPDATE2: I deleted the compiled Suite file and zipped the files again. Now it will upload. Hopefully you can help give some insight to this problem. Thank you.
UPDATE3: I tried to see if the #include "ifx.h" was the problem. I knew that I still required an #include, so I found that the ISRT.h file has the required header defines for the suite project and also for the registry information. So I commented out the include for the "ifx.h" and added an include for the "ISRT.h" and recompiled. I tested again and get the same error. There are no compile errors however.
QUESTION: I am wondering, since you ask us to remove references to the ifx.obl and isrt.obl; should we be using the #include for the .h files for these as well. Should my version of IS2013 include a script folder for issuite? I am just speculating here based on the pattern I am seeing in the script folder for MSI and based on the request not to use the linker files for ifx and isrt. I do not have a header file for the isrtsuite.h to include for compile that I can find anywhere in the scripts directory.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 27, 2014
06:47 AM
Josh,
BTW, the ISDbg.exe debug engine never loads. I do not think it ever gets to that point in the process. The debuglog file looks the same. So there is no debugging the InstallScript code.
Thank you.
Sincerely,
Daniel Lee
BTW, the ISDbg.exe debug engine never loads. I do not think it ever gets to that point in the process. The debuglog file looks the same. So there is no debugging the InstallScript code.
Thank you.
Sincerely,
Daniel Lee
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 27, 2014
08:57 AM
Does it make a difference if I am compiling these projects on Windows XP sp3?
The reason I ask is that an associate has successfully implemented your pattern, but I believe he is working on Windows 7. Our build machines however, as still configured around Windows XP sp3.
I have attempted this yet again with a new project and have been trying to alter the configuration just a little each time, but no success yet.
Sincerely,
Daniel Lee
EDIT: I installed IS2013 sp1 Premier on a clean Win7 x86 machine and copied over the project. It is not XP related because the same error occurs. Therefore I have to conclude that I am doing something wrong in how I am setting up my Preprocessor define, my linker obl file, or including files in the suite project.
The reason I ask is that an associate has successfully implemented your pattern, but I believe he is working on Windows 7. Our build machines however, as still configured around Windows XP sp3.
I have attempted this yet again with a new project and have been trying to alter the configuration just a little each time, but no success yet.
Sincerely,
Daniel Lee
EDIT: I installed IS2013 sp1 Premier on a clean Win7 x86 machine and copied over the project. It is not XP related because the same error occurs. Therefore I have to conclude that I am doing something wrong in how I am setting up my Preprocessor define, my linker obl file, or including files in the suite project.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 27, 2014
12:59 PM
Dan,
Looking at the attached suite project I noticed that the ISSetup.dll included in the suite's support files is the wrong file. The file included is the ISSetup.dll used for MSI style projects. Suite projects use the pure InstallScript version of ISSetup.dll. You should be able to resolve the error you are seeing with these steps:
- Remove the copy of ISSetup.dll from the Support Files | Language Independent view.
- Add ISSetup.dll from the following path: \Program Files\InstallShield\2013\Redist\Language Independent\i386\ISP (this must be the copy from the ISP folder).
- Rebuild and test your suite project again.
The error you are seeing is occurring long before the InstallScript debugger can be launched. The MSI version of ISSetup.dll (from the Redist\Language Independent\i386 folder) does not know how to launch InstallScript actions for suite installs. As a result an error occurs very early on in calling into that ISSetup.dll and you won't be able to run any script code or launch the script debugger. Once the correct copy of ISSetup.dll is used the debugger should launch when the suite is run with elevated privileges.
Looking at the attached suite project I noticed that the ISSetup.dll included in the suite's support files is the wrong file. The file included is the ISSetup.dll used for MSI style projects. Suite projects use the pure InstallScript version of ISSetup.dll. You should be able to resolve the error you are seeing with these steps:
- Remove the copy of ISSetup.dll from the Support Files | Language Independent view.
- Add ISSetup.dll from the following path: \Program Files\InstallShield\2013\Redist\Language Independent\i386\ISP (this must be the copy from the ISP folder).
- Rebuild and test your suite project again.
The error you are seeing is occurring long before the InstallScript debugger can be launched. The MSI version of ISSetup.dll (from the Redist\Language Independent\i386 folder) does not know how to launch InstallScript actions for suite installs. As a result an error occurs very early on in calling into that ISSetup.dll and you won't be able to run any script code or launch the script debugger. Once the correct copy of ISSetup.dll is used the debugger should launch when the suite is run with elevated privileges.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 27, 2014
02:05 PM
That was my problem. I am running smooth as silk now and debugging whatever is required without a problem.
Thank you very much.
Sincerely,
Daniel Lee
Thank you very much.
Sincerely,
Daniel Lee
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 27, 2014
03:06 PM
Another question ... I am sorry 😮
Are all InstallScript functions available in the Suite package other than UI related functions?
The reason I ask is that my calls to SYSINFO.nOSProductType are returning 0 and all calls to anything relating to SYSINFO return zero.
SYSINFO.WINNT.nServicePack should return a number indicating the value of the service pack.
SYSINFO.nOSMajor returns zero
Calls to the registry are working.
Thank you.
Sincerely,
Daniel Lee
EDIT: My script has #include "ifx.h". That has the correct reference to ISRT.h which references the ISRTWindows.h file that contains the proper structure for SYSINFO and stuff. I do not see information regarding SYSINFO directly there, but I see what is being used for SYSINFO.
Are all InstallScript functions available in the Suite package other than UI related functions?
The reason I ask is that my calls to SYSINFO.nOSProductType are returning 0 and all calls to anything relating to SYSINFO return zero.
SYSINFO.WINNT.nServicePack should return a number indicating the value of the service pack.
SYSINFO.nOSMajor returns zero
Calls to the registry are working.
Thank you.
Sincerely,
Daniel Lee
EDIT: My script has #include "ifx.h". That has the correct reference to ISRT.h which references the ISRTWindows.h file that contains the proper structure for SYSINFO and stuff. I do not see information regarding SYSINFO directly there, but I see what is being used for SYSINFO.
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)