Home > Articles > Web Services > XML

Building Plugins with C# Part 1

  • Print
  • + Share This
Interested in building plug-ins, but not sure where to start? In this first article in a four-part series, you'll learn how to put together a simple authentication plug-in for a project in C#.
Like this article? We recommend Be sure to check out the rest of this article series. In Part 2, you’ll learn how to use XML to validate users. Part 3 shows you how to use inheritance in SQL to have your applications load their own configuration files. Finally, Part 4 wraps up the series by showing you how to log your process, as well as some troubleshooting.

This article is the first in a four-part series that focuses on building and using plug-ins in C#. The task that I'll use as an example throughout this series is user authentication since it that works well for showing off the use of plug-ins. The information needed to authenticate a user is usually pretty standard across applications: you provide a username and password, and find out whether the attempt was successful.

The plug-in doesn't care how the application got the username and password, nor does it care what the application does with the result. The application calling the plug-in doesn't care whether the user authentication is done using a database lookup, a file lookup, or other means (such as LDAP or Active Directory authentication). Plug-ins are useful for this type of task because, as the application grows and the needs of the business grow, more plug-ins can be developed to handle different methods of authentication without touching any of the application code.

The sample application I'll use in this article is a simple Windows form that loads a plug-in, finds the correct class to use from the plug-in, and executes a method and processes the result.

Building an Interface

The first step in making the authentication plug-in, after creating a blank solution, is to create a common project. You'll use it to hold classes that will be accessed by both the plug-ins and the application that calls them. The object of doing this is to keep the dependancies down; there is little advantage in creating plug-ins if the application has to refer to the plug-in project to compile or run.

The new project to hold these objects is AuthenticationPlugin.Common. Right now, it will just contain one interface and one class that extends Attribute, which will be covered a little later in this article.

The interface used here is IAutheticationPlugin. As shown in Listing 1.1, the IAuthenticationPlugin interface has only one method: IsLoginValid, which takes a username and password as a string and returns a boolean value that will be true if the user has been authenticated:

bool IsLoginValid( string username, string password )

Each plug-in is in its own seperate project, as it will be in its own assembly that is loaded by the application. The project for each plug-in uses a project reference to refer to the AuthenticationPlugin.Common project to be able to access the IAuthenticationPlugin interface.

Listing 1.1

using System;
namespace AuthenticationPlugin.Common
       /// <summary>
       /// Interface for the AuthenticationPlugin.  Each plug-in that is
       /// developed for authentication must implement this interface.
       /// </summary>
       public interface IAuthenticationPlugin
        /// <summary>
        /// Authentication method
        /// </summary>
        /// <param name="username">Name of user as a string</param>
        /// <param name="password">User's password as a string</param>
        /// <returns>true if user is autenticated</returns>
              bool IsLoginValid( string username, string password );
  • + Share This
  • 🔖 Save To Your Account