View Full Version : .Net Installer class - when are the overridden methods called?

10-27-2005, 10:04 AM
I need to add some custom actions to my basic MSI project. I would like to do this using a .Net DLL (in c#) simply because I've already got some of the code.

I understand that I would need to implement a class that inherits from Installer class and overrides the Install, Commit, Rollback, and Uninstall methods and then create a component for my .Net DLL and set the .Net Installer Class property to yes.

When in the install sequence are the above methods called and is there any way to control this?

Do I implement one class inherited from Installer for each custom action needed? If, say, I need a custom action to modify a local file and another to check a user account, would I implement two separate classes (in separate .Net DLLs) for these actions and is there a way to specify the execute order of these actions?

Thank you,

11-03-2005, 02:06 PM
Danger, Will Robinson! :eek:

After a tremendous amount of screwing around, I have to recommend that you don't go down this road.

Three and a half weeks ago, I was in exactly the same situation you are in now. Two weeks ago, I had given up and rewritten the code in VBScript.

It is possible to get this to work. I even succeeded in getting it to work for a short period of time, but then continued modifications of the InstallShield project broke it again and I could never fix it again after that.

The bottom line is that Visual Studio helps you a lot by placing a sort of "managed code flange" in your MSI file. InstallShield, despite their advertised support for .NET, doesn't help you as much. There used to be one person in IS support who really understood the issues, and he tried hard to help people; but he has since moved on (still works for IS, I think, because he periodically posts) but cannot offer complete support for everybody.

There are many minor issues to overcome, and the simplest solution is not to try it.

If you did, and already got it working, I applaud you. But for the benefit of others who may come along later, I do not withdraw my comments. As I said, I know it's possible. But there are many traps and issues, and my overall conclusion is that it's just not worth it unless you have an enormous amount of managed CA code (say 1000 lines at least).

My $.02

11-03-2005, 02:36 PM
I decided my post sounded arrogant because it talks about "issues" but doesn't describe any of them. Here's one:

My managed CA code used SQLDMO.DLL to perform some database management tasks. (If you're not familiar with SQLDMO, it contains the COM interfaces uses by tools like Enterprise Manager.)

In order to call SQLDMO from managed code, my managed CA is obviously using COM interop. So there is an interop.SQLDMO.dll that has to accompany my managed CA.

When I built the CA in InstallShield, it included the interop DLL but also included SQLDMO.dll itself. The installer tried to register SQLDMO on the target system, resulting in errors because SQLDMO was obviously already there as a result of my MSDE 2000 installation prerequisite.

So I added SQLDMO.dll to USERSCAN.INI to filter it out of the dependency scan, just like the docs recommend. And guess what happened...it filtered out interop.SQLDMO.dll as well. I could have both or neither, but I could not find a way to get it to automatically exclude the real DLL but include the managed interop DLL.

I decided to try leaving the exclusion in USERSCAN.ini but manually including the interop DLL in my installation. This in turn required changing my CA from an "execute from binary stream" type back to an "installed with the project" type. The decision about which of these to use is another whole tangle that I won't go into here, and being constrained to the "installed with the project" type is not necessarily the right answer (I'm not sure, honestly).

So now I needed to figure out how to drop the DLL in the folder where the CLR will automatically probe for it when the CA runs. What folder is that? Well, I never was completely sure. I figured out how to drop a file in the temp folder and did that, along with other alternatives, but I could never get the CLR to find the interop DLL.

Obviously none of this stuff happens when you build installers with Visual Studio. They are doing a lot of stuff behind the scenes; they create something like three custom actions for each one you think you're specifying, and they know what to exclude and include in the MSI, and they automatically include the right set of dependencies. Of course I didn't realize any of this until I wasted a week and a half trying to get it all to work in IS.

You won't have this issue, you'll have different ones. Go there, or don't; it's up to you.