InstallAware

Please try the attached mMSIExec.dll. You can copy it to:

InstallPath\InstallAware 9 R2\Plug-Ins\MSXML

Copy/backup the old version before replacing.

Rebuild your project and give it a shot.

Nope, it doesn't work, still the same

First of all I quit IA, replaced the dll, fired up IA again and recompiled the project.

I first tried to uninstall an already installed application (installed with the "original" version of IA). It failed to stop and delete the services.

I recompiled the project once again and in order to "upgrade" an application installed with the "patched" IA. It also failed, the services was still running after the PVU phase.

Well - back to the drawingboard dudes and dudettes

I wonder if your service wasn't created properly, or not using the proper name or the control service command doesn't appear before Apply Install?
(I think the problem is your service, because you said it wasn't removed during an (Apply) Uninstall a well as Previous Version Uninstall (Uninstall MSI))

Here's how this is being tested (to ensure a proper service is being tested on):

Download Windows Server 2003 Resource Kit tools (these work on XP)
Install rktools.exe.

Run the following command (from command line):
The following results should be produced:

The service was successfuly added!

Make sure that you go into the Control Panel and use
the Services applet to change the Account Name and
Password that this newly installed service will use
for its Security Context.

You should now see a service called "ServeAny" listed in the services list (services.msc).

You could also query the service by calling the following from command-line: Create a new basic project and add this line to the very start: Build and install.

Run the attached UninstallMSI.exe and enter your product code (including {} braces), then click Remove.

You should then see the service has been removed from the list and sc.exe query produces no result.

Note that the UninstallMSI.exe that I created only calls (Un)Install MSI [removeall], so your previous version uninstall should do the trick. The one I uploaded is using the latest version and is verified to remove the test service I'm creating with instsrv.

If you can uninstall a service created by instsrv, but not yours, I guarantee the problem is your service and not the Control Service stop and delete nor the (Un)Install MSI commands.

No, you've missed out on the basics;
The service actions -only- fails during PVU.
Both actions, stop & delete, succeeds when uninstalling the app by running the same installer again.

What OS are you testing on?

Can you post the service you're trying to work with?

I've tested this particular problem in several machines with different OS in order to figure out why it fails.
(mainly WinXP & Win2K3)

This problem was, as mentioned before, previously reported in IA 9.0.4 and fixed in IA 9.0.6, see http://www.installaware.com/forum/viewt ... f=2&t=4920

All of our customer installs are made in either Win2K3 or Win2K8.
(Not that is should make a difference as a win service can be registered in practically any windows OS...)

Note that this problem is not bound to a particular installation or service.
I have one installer where I have four services registered and all four fails to stop & delete on upgrades.
None of these services have any dependencies...
Still, what I can't figure out is why stop & delete works when uninstalling the application "manually" but not when the uninstallation is automatic through PVU...?
Is it different scripts executed in these two variants?

During the uninstall, Apply Uninstall is called. During the previous version uninstall, (Un)Install MSI is called.

I was seeing the problem you describe (In IA 9 R2 SP3). The mMSIExec I posted fixes this problem for me. Note that replacing it in your project folder will not fix it. It has to be replaced in the IA plugins folder...

The UninstallMSI tool I posted implements the updated mMSIExec which implements the (Un)Install MSI command.

There are two other customers which have posted services they had issues with. I can no longer reproduce it using their services and I'm confident I wouldn't see a problem using yours, either.

So, you can install your product, then run the UninstallMSI tool I posted and see if the service exists afterward to test. That simulates the previous version uninstall.

I'm still struggling with this...
I've tested your Uninstall MSI Test and it works like a charm, all services were stopped and deleted, but when running my freshly compiled project it fails.

I've checked and double-checked the mMSIExec.dll you provided and this is -exacly- the same as the one currently residing in my MSXML directory.
(D:\Program Files\InstallAware\InstallAware 9 R2\Plug-Ins\MSXML\)

But this is -not- the same as the one in the actual project directory after compilation(?!?)
When the project is compiling another version gets copied to the proj dir (and probably embedded and shipped along the installer, correct me if I'm wrong....)

As the dll lacks versioning I'll provide best info I've can offer, namely the size props;
The one in the proj dir is 438 272 bytes and the one you provided and copied to MSXML folder is 438 784 bytes.
Clearly not the same...

Whats the point of copy the dll to the plugin's folder when it aint used anyway?
Is there an additional step I have to take apart from just copy the file?

I was able to reproduce a similar situation. I deleted the mMSIExec.dll in the project folder and rebuilt, then the dll matched the version in the plugins folder. It's possible that, since it sees one in the project folder already, it isn't being copied...

The correct version should be:
438,784 bytes
Modified on Oct 3, 2010, 10:14AM

I did the same as you, deleted the one on e project folder, but the 'bad' version is still being copied there instead of the one in msxml folder during compilation..?

I -finally- got it sorted!

I basically made a system search of this darn mMSIExec.dll and also found it in another IA plugin folder; MSI Shell.
This was actually the one copied to my project during compilation, not the one in MSXML folder, dont ask me why...

Well well, I replaced this one also and the problem is now resolved, everything seems to work just fine.

I really hope you guys get this mess sorted out before shipping the next IA update.