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: InstallScriptMSI vs BasicMSI
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎May 11, 2009
04:28 PM
InstallScriptMSI vs BasicMSI
I'm running into a problem that is very confusing. When I created the project I could have sworn that I created an Installscript MSI project, but looking at the Start Page, it has it labeled as a Basic MSI. When I am running my installation, the installscript custom actions that I have created are not running in the correct spots. My install custom action have to be placed after InstallFinalize, or it happens before the file copy happens, even if they are placed after Install Files, causing them to fail. (They call one of the files that is installed.) When I run my uninstall custom action, it is happening after the files have been removed, causing it to fail because the file it calls has been removed. Is this being caused because it is a BasicMSI package? Would changing to an Installscript MSI package change this behavior?
Thanks,
Thanks,
(5) Replies
‎May 11, 2009
04:38 PM
Not sure why anything would have changed, but perhaps first verify that the actions are scheduled for deferred (and not immediate) execution, between InstallInitialize and InstallFinalize (such as after InstallFiles)...
‎May 11, 2009
05:20 PM
RobertDickau wrote:
Not sure why anything would have changed, but perhaps first verify that the actions are scheduled for deferred (and not immediate) execution, between InstallInitialize and InstallFinalize (such as after InstallFiles)...
I did have the CAs set to immediate execution, but after changing them to deferred execution, even though they seem to execute after the files are copied (based on the UI), the CA is still unable to locate the file. I've checked the directory, and the file is there, but the code that I have in the CA does not find it. This is the code that I'm using to register my function.
// Register the NT Service
function RegisterService(hMSI)
STRING szLaunchApp, szCmdLine;
begin
MessageBoxEx("Register NT Service CA", "DEBUG", INFORMATION);
// Run Installsupport
szLaunchApp = TARGETDIR ^ "TMService.exe";
szCmdLine = "-i";
if(Is(FILE_EXISTS, szLaunchApp)) then
MessageBoxEx(TARGETDIR ^ "TMService.exe exists", "DEBUG", INFORMATION);
LongPathToQuote(szLaunchApp, TRUE);
LaunchAppAndWait(szLaunchApp, szCmdLine, LAAW_OPTION_WAIT);
szCmdLine = "-r";
LaunchAppAndWait(szLaunchApp, szCmdLine, LAAW_OPTION_WAIT);
endif;
MessageBoxEx("Service Registered", "DEBUG", INFORMATION);
end;
I've used this same code many times before in Installscript projects, and never had a problem, but moving to MSI based projects seems to be a completely different story. From what I can see the file exists, I've checked the directory at the first message box, and the file is there, but the code does not see it.
Additional information: If I remove the if statement, it appears that the script is not seeing the TargetDir variable. Before I changed to defered, this variable contained the directory where I was installing the file. I have also tried the InstallDir variable, and get the same results. How do I locate the directory that my files are contained in so that I can find them to execute them?
‎May 11, 2009
05:53 PM
Right, it's a couple of things; MSI projects use INSTALLDIR as the destination, and deferred script custom actions need to use a special property called CustomActionData to get property values in deferred mode. (The help and these forums have examples.)
Before worrying about that, though, you might look into using Windows Installer's service installation and manipulation functionality, or (if that doesn't cover it) using a launch-an-EXE custom action.
As a rule of thumb, using built-in MSI functionality instead of custom actions helps with uninstallation, rollback, elevated privileges, and a bunch of other things...
Before worrying about that, though, you might look into using Windows Installer's service installation and manipulation functionality, or (if that doesn't cover it) using a launch-an-EXE custom action.
As a rule of thumb, using built-in MSI functionality instead of custom actions helps with uninstallation, rollback, elevated privileges, and a bunch of other things...
‎May 12, 2009
11:33 AM
Thanks Robert,
Other things happen during the execution of the TMServices.exe, so I'm not able to use the built in install functions. I have switched over to a launch an exe type custom action, and that seems to have solved the problem. I should have thought of that before, but I'm just not comfortable with the MSI based installations yet. Have you run into any good reference material. I have the old Installshield Press book (©2004), but would like to find something a bit more recent. Any suggestions would be appreciated.
Thanks again for your help.
Other things happen during the execution of the TMServices.exe, so I'm not able to use the built in install functions. I have switched over to a launch an exe type custom action, and that seems to have solved the problem. I should have thought of that before, but I'm just not comfortable with the MSI based installations yet. Have you run into any good reference material. I have the old Installshield Press book (©2004), but would like to find something a bit more recent. Any suggestions would be appreciated.
Thanks again for your help.
‎May 12, 2009
12:33 PM
The good news is, Windows Installer's service-related functionality hasn't really changed. For more recent InstallShield information, there are training manuals and other publications listed here: http://www.acresso.com/services/education/publications.htm. InstallSite has a list of publications, too.