When to use Installer classes?

[Roy Chastain]

After reading posts in this newsgroups, I have noticed a couple of people that appear to have a good grasp of install process and
Installer classes indicate that they are not necessarily a good thing.

I would like to start a discussion on the topic of when and why using an installer class is a good or bad idea.

One of the posts I read asked the question (not of me) of 'why are you using an installer class' and continued to say that there
is almost always a better way to do the same thing.

As a starting point to the discussion, I would like to answer that question.

I started looking at installer classes because they seemed like an easy way to handle many special processes that are not easily
handled in MS Installer (either via the InstallShield or VS GUI). I was also under (the perhaps mistaken) impression that these
classes would have better integration with the complete install process than a simple command line type program that would be
executed with a 'wait for completion and check status operation' would provide. (The more I understand, the more I doubt that
belief.)

In my case I have 2 uses of Installer classes.

One of them is used to control the creation of SQL databases. Either in an existing SQL server or in a copy of MSDE that we
install. In this case, I believe that this functionality could be performed without the Installer class. Again the idea was
simply to provide what I believed (and now hope) better integration with the complete install process.

The second use is to control the installation of a Windows Service and the Performance counters that are being used by that
service. In this case, InstallShield GUI has pretty much adequate capabilities to install the service, but it has nothing for
Performance counters. I figured if I was going to put the installer class in for the Performance counters, I might as well have
the service stuff there too. That makes in one nice and complete package that could, in a pinch, be installed by InstallUtil
instead of the .msi file. Seemed like a good thing.

One might question the use of the Installer class for the Performance counters. Well, I have done Performance counter
installation via the installer class and I have done it by writing all the code to create the counters etc. While it is not
difficult to do things in the code, the installer class was even easier and I got it right first try.

I guess finally, that (as some people accuse me of) being an optimist, that I am hoping that in the future there might be even
more flexibility and integration built into the installer classes, so why not start with them now.

That is my two cents worth. I would like to hear from anyone with similar or different views and I would particularly like to
hear from anyone with actual knowledge on the subject.

Thanks

 

[Peter Huang [MSFT]]

Hi


I think the Installer class under the System.Configuration.Install
Namespace is used to help simplify the procedure to configure in managed
way.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemconfigurationinstall.asp
e.g. A typical .NET windows Service project will use a Installer to do the
configuration such service name,start type ....

Also .NET provide a tool to execute the installer class in the component.
Installer Tool (Installutil.exe)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/htm
l/cpconinstallerutilityinstallutilexe.asp

The installer class is also applied to the scenario below.
Walkthrough: Using a Custom Action to Pre-Compile an Assembly During
Installation
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/ht
ml/vxwlkwalkthroughusingcustomactiontoprecompileassermblyduringinstallation.
asp

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Phil Wilson]

Everything that you can do with Installer classes can be done with a C++
custom action Dll in a simpler and more functional way. There's no shim Dll
infrastructure between Windows Installer and your code, and so the C++ call
is more transparent and robust. Installer classes are always a bad idea IMO
(and this guy's too):

http://blogs.msdn.com/astebner/archive/2005/03/10/392280.aspx

People would rather not use unmanaged C++ after they've moved to managed
code, but I'd argue that setups are a specialized area where it should be
used, just like there are other parts of the Win32 world where there isn't
much support for managed code. It's somewhat like complaining that you can't
write a driver in C#.

To me there's no point in using Installer classes to install Services. I
don't understand why anyone would prefer a bunch of code to install a
Service when Windows Installer has perfectly good table-driven support for
this in the ServiceControl and ServiceInstall tables. Why Visual Studio
chooses Installer classes for installing Services is beyond me, but if you
use VS setup projects, you don't get a vote, you're steered to Installer
classes for this. Plus the ServiceInstall table lets you set the darn
Description, something Installer classes don't do.

VBScript custom actions are quite popular and capable for many things, but
they can have issues with some antivirus products. This is probably why some
installs tell you to turn off AV before starting.

Another reason people use Installer classes is that they are unfamiliar with
the capabilities of setup projects, Windows Installer properties, and the
guts of what it means to perform various installation tasks like
registration. I've seen people write an Installer class to write a value in
the registry because they were unaware of the Windows Installer property
TARGETDIR. I've seen people running regsvr32, gacutil, and calling
RegistrationServices code because they don't understand the Register
properties in VS, can't find how to install an assembly in the GAC, or don't
understand enough about .NET COM Interop to know how to register their
assembly and a type library, but they do know that the equivalent of running
regasm will work.

In your SQL case, you just need a custom action to create the database, but
I wouldn't use an Installer class, I'd write a separate program and cause it
to run as a custom action or after the install has finished. This type of
solution often has the advantage that there's some standalone code to create
the database and so you don't need to re-install the product to re-create
the database.

As for perfmon counters, the other minimal coding technique I've always used
is this:

http://msdn.microsoft.com/library/d...er_names_and_descriptions_to_the_registry.asp

The issue is that Visual Studio setups don't provide a clean way to run a
program that you're not installing, so this also steers people in the
direction of Installer classes. I'd rather user a C++ custom action DLL call
to run lodctr/unlodctr from a C++ call than write all the code to create and
undo the registry entries in the VS case, but InstallShield will let you run
a custom action (type 50 probably) to run lodctr/unlodctr with a command
line.

Folks that need more than VS setups offer have something like 20 tools to
choose from. Some are cheap or free, some aren't. Wix is good, but it does
expose you to the innards of setups compared to VS and others that have IDE
support to hide those innards.