Building Plugins with C# Part 4: Logging and Deployment
- Using the Exception Manager Application Block
- Keeping A Log
- Deployment
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This is the last article in a four-part series discussing techniques you can use to build solid plug-ins using C# .NET. I'll show you tweaks you can make before implementing an app or service, to take advantage of a plug-in architecture. One of them—a subject that is important in Web or Windows services—is logging. Another is using the Setup and Deployment project in the Visual Studio IDE for deployment.
Using the Exception Manager Application BlockApplication Blocks let you easily provide extra functionality to an application and decrease the time you have to invest in creating some of the pieces. Among the Application Blocks are the Configuration Management Application Block, Data Application Block, and Exception Management Application Block. In this article, I'll show you how to use the Exception Management Application Block to log errors and messages as they occur in the test application and plug-ins.
Remember that the plug-ins must handle their own errors and not propagate them to the application that is calling them? In many cases, all the plug-in can do is catch all errors and log the details of the errors somewhere. Using the Exception Management Application Block, it's easy for an application to write the details of an exception out to the Windows Event Log. This has a couple benefits: the Event Log is managed by the operating system, so the app doesn't need to concern itself with logging and the management of output files, etc.; and the Event Log provides ways for a normal person to remotely view messages through the Microsoft Management Console.
Before you can begin using the Microsoft Exception Management Application Block, first download it from Microsoft's site. You get the full source code in an MSI file, so you can compile the block yourself and view the documentation and samples that come with the download.
A note, first, about using these Application Blocks in a team environment. When I use the Exception Management Application Blocks in a solution that is not under source control, I sometimes add the Microsoft.ApplicationBlocks.ExceptionManagement and Microsoft.ApplicationBlocks.ExceptionManagement.Interfaces projects to the solution from the installdir\Code\CS\ directory, where installdir is the directory in which the Application Block was installed.
If the solution is under source control, you should follow the guidelines established for your company or project; I've seen situations where components like these are checked into source control both in a central location and in a per-solution basis. There are valid arguments for doing it either way. On one hand, centrally locating the Application Block code can give your projects at least one benefit; if the projects are modified in any way after they were downloaded, all the projects that refer to them benefit from the changes. On the other hand, this means any change requires regression testing for all of your applications. One small change could break a lot of code.
Having the Application Block checked into source control under each separate solution turns the solution into an island that is safe from changes made to the same Application Block elsewhere. However, this can introduce an administrative nightmare should any Application Blocks be updated.
Alternatively, the Exception Management Application Block solution can be compiled. Then you can either add the assembly from the Application Block to the global assembly cache, or make a reference to the assembly instead of adding the project to the solution. Depending on how you use the Application Blocks, this might be the cleanest route. But it's not without extra work. The Assembly must strongly typed and added to the global assembly cache on the servers on which the app will run. Some administrators may become a little cranky about making that kind of change without a lot of testing.
After you add the references to the Microsoft.ApplicationBlocks.ExceptionManagement project or assembly to the app, add:
using Microsoft.ApplicationBlocks.ExceptionManagement;
to the top of the class that will use ExceptionManagment. In the project for the solution's testing app, AuthenticationPlugin.UI.UITester, I added the statement to the top of the Form1.cs file. In the Form1 class, there are several try...catch blocks that called a method I had created called ShowError. The purpose of this method is to pop up a message box from the testing
app that tells me that something went wrong, such as an invalid cast or a plug-in that was missing the implementation class altogether. In the btnLogin_Click method, I changed the code that catches the InvalidCastException to:
catch ( System.InvalidCastException ice )
{
/* The object didn't implement the IAuthenticationPlugin interface, and could
* not be cast correctly */
ShowError( "The authentication object does not implement the correct interface." );
ExceptionManager.Publish( ice );
}
The new call to ExceptionManger.Publish, which accepts the InvalidCastException ice, publishes the details of the exception to the Application event log. You can view the log entry by going to Event Log under Administrative Tools in the Control Panel. The details will look like:
General Information ********************************************* Additional Info: ExceptionManager.MachineName: MYPC ExceptionManager.TimeStamp: 5/31/2004 10:24:05 AM ExceptionManager.FullName: Microsoft.ApplicationBlocks.ExceptionManagement, Version=1.0.1612.16079, Culture=neutral, PublicKeyToken=null ExceptionManager.AppDomainName: AuthenticationPlugin.UI.UITester.exe ExceptionManager.ThreadIdentity: ExceptionManager.WindowsIdentity: MYDOMAIN\myuser 1) Exception Information ********************************************* Exception Type: System.InvalidCastException Message: Specified cast is not valid. TargetSite: Void btnLogin_Click(System.Object, System.EventArgs) HelpLink: NULL Source: AuthenticationPlugin.UI.UITester StackTrace Information ********************************************* at AuthenticationPlugin.UI.UITester.Form1.btnLogin_Click(Object sender, EventArgs e) in c:\temp\autpluginspart4\authenticationpluginpart4 authenticationplugin.ui.uitester\form1.cs:line 155 For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
That's quite a lot of information. By passing the exception into ExceptionManager.Publish, you can get the exception name, message, and stack trace. Even the line of code in which the exception was thrown is included in the output.
The Publish method has two overrides, so it can also take a NameValueCollection that contains additional information as a parameter. The additional information can include information about the state of the object, the application, or any other message that you might want to share with the person viewing the logs, to help in tracking down and resolving the problem.
Another very useful feature about the Exception Management Application Block is that it can be extended with custom publishers. With no configuration out of the box (or MSI file), it logs to the Event Log. It can also log to a database, to a file, or to any medium that you can persist to with a custom publisher.