I don't get \"Control Service\"

[mannaggia]

I'm evaluating InstallAware and my installer creates a Windows service. That works OK.

I want to be able to run the same installer again and have it upgrade an installation to a later version. That is, I don't want the user to have to uninstall the older version, or do anything else other than run setup.exe.

So in my installer, I check to see if my .exe file already exists and if it does, it checks to see if the service has a status of "RUNNING". It does that OK.

But when the service status is "RUNNING", I then run a "Control Service" script command with the parameter "Stop the service on install" and check the "Wait for state change".

However, the service does not stop at that point! Is it supposed to stop? If not, when is it supposed to stop? Can I do what I am trying to do?

I know it gets to that line in the script because I put a message box just above it and it displays.

(This is how I handled it in my Wise InstallBuilder script and I want to do it the same way with InstallAware.)

[jimo]

The "Control Service" action is a Windows Installer command and will not execute until the Apply Install action.

All commands in purple will not execute until the Apply Install action.

[mannaggia]

OK, that explains it - I was looking at it as a true script that ran from top to bottom.

I'm still having trouble though with updating the .exe file for my service.

When I run the installer on a clean system for the first time, it installs/creates/starts the service with no problems.

So then I wanted to test what would happen if I released a new version of the service executable.

In the install script, at the very beginning I check to see if the service is already installed and running. If it is, I do an Run Program and run a "net stop" command to stop the service so the .exe can be overwritten. I also set a flag in a variable denoting this.

Then later in the script I check the flag - if the service didn't exist when the installer started, it does an "Install Service" command.

If the service did already exist, I just want to update the executable file, so I do an "Install Files" command to install the new version of the .exe.

In my tests, it NEVER updates the .exe. The IF statement is triggering properly (tested by inserting a MessageBox), but the .exe file is never overwritten.

I checked and the service has indeed stopped, and the file I am trying to overwrite it with has a date later than the existing .exe file and the version number is later than the existing .exe file.

So how can I find out why it will not overwrite this file?

I tried using a "Delete Files Recursive" command before the Install Files and that does delete the file, but Install Files STILL does not install the file!?!

What is Install Files looking at to determine whether or not it needs to install the file?

Is there no way to simply overwrite an existing file, no questions asked?

Thanks!

[MichaelNesmith]

I think it might be better to use an Install Service again. You want to make sure MSI is happy and not confused about what's going on, since the same file is targeted by two separate commands. That might solve the problem for you. Also make sure Apply Install is called after each command.

MSIcode presents a drag-drop scripting environment just like WiseScript, but because the underlying technology is MSI, a few compromises have to be made. These are in the following forms:

1) Nothing purple happens until Apply Install is called. Purple commands are directly translated into MSI database entries and they can be thought of as "cached" until Apply Install is called, which invokes Windows Installer to perform the actual installation.

2) Everything else does execute directly. This might be confusing because some commands appear delayed whereas others are immediate.

This caveat does have the following benefits, however:

3) Apply Uninstall automatically undoes everything that was carried out by the last Apply Install.

4) When changing setup feature sets, it is not necessary to manually un-do purple commands either, just like #3 above. So lets say you have some branching If's in your MSIcode (typically used for features). If some of those branches executed in the last call to Apply Install, but are not executed in the current Apply Install (ex: a feature previously selected is no longer selected during a maintenance), there is no need to manually undo actions that are now not-executing. Similar to #3, Windows Installer will roll them back automatically.

So you just code a single linear script which executes without requiring manual logic for toggling features on or off based on maintenance selections. Actions that were previously done are automatically undone for you if no longer required, similarly new actions that are now newly done are automatically done. This naturally helps you maintain your setups easier - a single code block for all install functions.

[mannaggia]

I will try the Install Service tomorrow and see what that does.

I was not doing that because I do not want it to "re-create" the service. I don't know if it does that or not, but what can happen is that we originally install the service to run in the System Account, but users may change the service parameters in the Control Panel Services applet to run the service as a different user and I don't want to overwrite any manual settings the user made. I just want to update that one .exe file.

[mwilner]

@Michael Nesmith

Michael,
The advise to use Apply Install after a service call was the best that I have seen here so far.
I have been battling with this issue for a while that I needed to stop/start services before doing other tasks but it wasn't clear to me that I can use Apply Install a number of times and HAVE to use it after a service call. This is solving a big problem I had.
Thank you!