-
Delete the default Class1.cs object from the MyInstallerClassDll project by expanding the Solution Explorer, right click on the Class1.cs object and select the Delete option.
- Enter the code window for MyInstallerClass object, it should be something like the code below:
Code:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Configuration.Install;
namespace MyInstallerClassDll
{
[RunInstaller(true)]
public partial class MyInstallerClass : Installer
{
public MyInstallerClass()
{
InitializeComponent();
}
}
}
|
That's it, those are the steps to create an Installer Class. As you can see it is inheriting from the Installer abstract class, and because of this, several installation events are exposed for you to override, like:
- Commit
- Install
- OnAfterInstall
- OnAfterRollback
- OnAfterUninstall
- OnBeforeInstall
- OnBeforeRollback
- OnBeforeUninstall
- OnCommitted
- OnCommitting
- Rollback
- Uninstall
All these events come to life when your installer class object is assigned as a Custom Action to a Deployment Project. These events by default are empty and you should code the logic to the ones required by your deployment project.
There are some unwritten rules and unpleasant features when using these events imposed by the way Deployment Projects behave at run time.
The sequence these events are raised is shown next:
Play attention to the facts: (a) untrapped exceptions on the OnBeforeInstall event will not trigger any of the Rollback events; and (b) you may reach the Rollback events from anyone of the installations events.
UN-WRITTEN RULES
- All these events should be bullet proof without throwing unexpected exceptions, if anyone of these methods throw an exception the installation or uninstallation request will fail.
- It does not make much sense calling the Rollback event in the middle of a different event; you should implement these events independent of each other, your installation class may have common methods shared by these events, but cross calling installation related events are risky business.
- Practice extreme caution when coding the Uninstall event, failure to do so may render your application un installable.
- If you are using the savedState event's variable (more about this variable later), you should assign your installer class to all the Custom Action's modes (Install, Commit, Rollback and Uninstall) in the Deployment project.
- Your installer class should not reference classes located outside its assembly because there is no way to know if those assemblies will be available (installed) at the time you reference a class or method from an external assembly.
UNPLEASANT FEATURES
- None of the deployment project's properties is automatically available within your installer class.
- Your Installer Class could be instantiated several times by the Windows Installer (installation) process, for this reason you can't rely on global variables to keep track of its different stages, that's why you should use the StateSaver and SavedState objects explained later on this article.