Share Your Code By Writing Class Libraries

What is a Class Library?

In the .NET Framework, a class library is a collection of classes and interfaces that can be reused by different applications. Class libraries are packaged and distributed as assembly files (with extension .dll). The .NET Framework itself provides a large number of class libraries to use in your applications. For example, any time you use the MessageBox class in your application, you’re using the System.Windows.Forms class library.

If you’ve written an Eclipse Scripting API (ESAPI) binary plug-in, you’ve written a class library. It is stored as an assembly file that is later loaded and executed by Eclipse. However, this class library is only meant to be used by Eclipse, and therefore is not really reusable. In this blog post I’ll discuss the benefits of creating additional class libraries to support your scripts.

Why Use Class Libraries?

Creating a class library allows you reuse your code in different scripts. For example, you may need to use the same analysis in a plug-in script and in a stand-alone script that runs a batch of cases. Instead of duplicating the analysis code in each of these scripts, you can create a single class library that is used by each script.

Writing a class library forces you to decouple different aspects of your code. You don’t want to have code that deals with the user interface mixed in with code that does the analysis. Moving the analysis away from your main application helps you to break those dependencies.

A class library can have its own version. This helps you to keep track of how your library changes and grows through time, independent of the scripts that use it. This means that you may want to keep your class library in its own version control repository (more on that later).

Unit tests are best maintained in their own class library. They’re conceptually different from the main code, so you want to keep the tests separated. The unit test library needs to depend on the main code in order to test it, but the main code should never depend on the unit test library.

A class library written in one .NET language may be used by an application written in another .NET language. So if you’re more comfortable with Python, you can create a class library using IronPython (see my blog post on ESAPI Programming with Python), and it may be used by a script written in C#.

Despite these benefits, it’s sometimes unnecessary to create a class library. If a group of related classes makes sense only in the context of an application (and won’t be reused), there’s no reason to separate them into their own class library. Instead, you can put related classes in a new folder within your main project. For example, in an MVVM application, you may have the folders Model, View, and View Model. Visual Studio will automatically create a namespace for each folder, which helps to keep your related classes grouped together.

Creating a Class Library

To create a new class library in a solution, right-click on the solution name (in the Solution Explorer window of Visual Studio) and choose “Add,” then “New Project.” In the dialog box that appears, choose “Class Library” and name your library. For example, if you’re developing a set of classes to perform DVH analyses, you could name your library “DvhAnalysis.”

If this class library is going to be used by more than one script, I recommend that you create it in its own solution. Also, use a new repository to maintain its own version history (see my blog post On Using Git Well). Even though the class library is in its own solution, you may want to reference the library project from the solution of a script that will be using it—at least at first. This will make it easier to develop the library as you develop the script. Just remember to update the repository of both the script and the class library.

Once the library is mature and properly tested, you can stop referencing the project directly from your scripts. Instead, you can “release” it by putting it in a shared location so that anyone who wants to use it has access to it. For example, the DvhAnalysis class library may be located in a shared drive, in the folder Shared\DvhAnalysis\1.2.0.0. Having a folder for each version is a good idea, as you may have different scripts using different versions of the library.

Now, any script that wants to use your class library can reference the .dll file in the shared location. If you need to update the class library, you need to re-release it with a new version. Any script that would like to use the new version would need to reference the new location. This method adds a few extra steps to the process, but it helps in avoiding confusion about which version of a library is being used by a script.

As I discussed in Version Conflicts in ESAPI Scripts, you may want to name your class library with its version number (unless you can strong name it). The reason is that if you run two scripts using different versions of your library in Eclipse, it will get confused and only use one of them, or it will crash.

Using Your Class Library

In the project that will use your new library, add a reference to the assembly of your library. To do this, right-click on the “References” section of the project and choose “Add Reference.” In the dialog box, click on the “Browse” button to locate the assembly. Finally, in any class that will use your library, add a “using” statement with the namespace of your library. You’ll be able to use the classes in your library immediately.

Leave a Reply

Your email address will not be published. Required fields are marked *