In my C# windows service project I have a ProjectInstaller, and I put an override in for the Commit handler. In that handler I simply start the service just installed. This works perfectly for a new install using an MSI file. But if I have an older version already installed, the install of the new service works, but the Commit handler never gets called. I can prove this with more custom code to write to a log file - no file ever gets created.

I also tried this with a C# AfterInstalled handler, same results.

At first I thought it was because I forgot to bump the version number in the AssemblyInfo.cs. But even after I did that I got the same behavior. I can see the new version did in fact get installed (viewing its exe file properties in Windows Explorer I can see the newer version number).

Is there something else in the MSI setup itself (which I inherited so i'm not totally familiar with its inner workings), such that my Committed handler would get called for a new install but not for an "upgrade"?

Tim

You've probably got this:

http://support.microsoft.com/kb/906766/en-us

where the older assembly is being used instead of the new one.

The older assembly didn't have any custom actions defined. I defined a Committed handler in the new version in order to self-start the service after it's installed.

I can't actually try the signing/strong-naming suggestion since my service links in a 3rd-party dll and all component dlls have to also be signed. Plus I'm not sure what the impact of working with a signed-service is, for example does my tray-app controller also have to be signed to use the signed service?

I'm not quite sure why this is regarded "as-designed", if in fact it's using a custom action of the old service (ie the one I no longer want, and am uninstalling) INSTEAD OF the custom action of the new service (the one I do want and am installing). That sounds like a bad design / bug to me.

If you are installing services then I think you must have custom actions because that's the way Visual Studio installs services, and that's what the installer classes do. You might not have any of your own code in the service/project installer classes, but you do have custom actions in the custom actions view in the setup project's IDE, right?

It's as-designed because once an assembly is loaded, an attempt to load another identical assembly doesn't do a load. In other environments it might be more obvious, but the old and new assemblies are identical in name, version, publickeytoken, but the code is in fact different. In .NET if you generate a new assembly with different code you're supposed to change something like the publickeytoken otherwise as far as .NET is concerned the assemblies are identical.

IMO the larger design issue here is the use of .NET managed code custom actions to install services. Windows Installer has built in support for installing and starting services (ServiceInstall and ServiceControl tables) that Visual Studio doesn't use, although every other setup tool does.

See http://installsite.org/pages/en/msi/tips.htmInstalling Secvices with Visual Studio for more history and another way to ge services installed and started.

The other group uses Installshield, which they won't share with me (different problem!), so I assume they do have custom actions although I have no idea what those actions do. I just don't have a custom action override in my C# installer class code, except for the Committed handler which self-starts the service.

I did change the version string in AssemblyInfo.cs, which I thought would make the old and new assemblies "different enough", but it evidently doesn't. Strong-naming the assembly seems overkill to me.

In the end I just asked the Installshield group to provide their own custom action to start the service after install is complete. I have no idea what tool/script they use to do that, but when they did it worked fine, and I removed my C# custom action code altogether.

I agree it's .Net's problem - in the installer class, there are plenty of other design-time configurable properties like service-name, display-name, user-account, automatic vs. manual. Why not just add a flag for "start after installation" to that class? Or, as you say, provide support for the service tables you mention.

Thanks for your posts.