Tech Off Thread

2 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Installer classes

Back to Forum: Tech Off
  • User profile image
    W3bbo

    I've made a little project that creates a Windows Service, Event Log, and an MMC snap-in.

    Naturally I made use of the System.Configuration.Install.Installer class in all of these cases.

    ...except I don't like how it works, it all seems like magic, and doesn't behave the same in all cases. For example the SnapInInstaller class, for installing MMC snap-ins requires you to create a subclass with absolutely nothing inside it, just marked with the RunInstaller attribute and then InstallUtil picks out all of the classes that derive from the SnapIn class (or is that classes marked witht he SnapInSettings attribute?).

    But for Event Logs and Services it's different: you subclass Installer directly (with the RunInstaller attribute) and create instances of EventLogInstaller and ServiceProcessInstaller, set them up right, and then add them to the base.Installers collection.

    It all doesn't seem right. Where are the design patterns and stuff?

    Ordinarily this wouldn't be a problem, but InstallUtil isn't the best installer (from a usability perspective). The logs are verbose, aren't timestamped, and impossible to parse, you have to read them manually every time. It doesn't provide detailed exceptions reports either (and Bill Gates help you if you get a "Exception has been thrown by the target of an invocation" error).

    Finally there's the magic "Installer class" property of Custom Actions in VS Setup projects which somehow causes these installers to get fired without giving you any control over them.

    Whilst the pre-built Installer logic saves time initially, it just ended up costing me the time I had to spend on figuring out strange error messages during installation that wouldn't have happened if I had direct and proper control over installation myself.

    Writing my own installation logic wouldn't be a problem if the .NET Framework exposed functionality for doing this, but instead it's all wrapped up behind their Installer classes, so I have to reimplement them myself.

    Has anyone else been in a similar situation?

  • User profile image
    davewill

    direct and proper control over installation myself.

     

    We use the WiX toolset for installation control.  Although I don't know that it would help you with overall time as you would need to learn something other than the time you already spent on VS setup project.  I specifically stayed away from VS Setup projects when .NET came out because of my past experiences with lack of control in prior VB Setup projects.  The setup project idea is good for quick and basic installs but when it comes to more complex stuff we ended up spending more time working around the roadblocks (well intentioned and purposed).

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.