A basic review on making a VB.NET Class Library using Visual Studio 2005

Introduction

This is a quick tour on making a .NET DLL or your own class library.

I had spent a little time cleaning up all of my drawing routines in my project DesignLab^(C) 2007 before committing to building a class library. Just to clarify, there is no reason to do this without cause. The cause represents the need/desire to use routines in various programs. I had begun to see ways to use my drawing engine in other applications, such as screen savers and animation.

A class library will have much of the data (properties) included with routines (methods) to set it. Other data may be provided by arguments to routines. My drawing routines all require an array of points to define the object, which is up to the user to construct, so these are passed in as arguments. In addition, there are numerous attributes for a number of categories such as outline, outline only, forecolor, hatch style, hatch color, draw width etc. In a case like that, I did routines in the Class Library to set those associated parameters in one subroutine or method.

I exposed the structure so the user could get or set any parameter individually, but the higher level routines help organize the usage so that with about a half dozen set calls, you would be guided through the approximately 40 parameters the engine needs to draw an object. Color in itself becomes complicated because in GDI+, you are always concerned with using alpha with each color specified.

My project has four distinct layers:

1. Main form selection establishes all of the drawing criteria.
2. A layer transforms main form requests into two drawing structures.
1. A structure that controls object selection and generation, number, size, tiling, composition, etc.
2. A structure that controls the drawing engine, transparency, hatching, six colors, brush, drop shadow, highlight etc.
3. A layer that transforms objects in drawing engine point arrays.
4. The drawing engine that needs layer 2B and layer 3 as input.

Because I was interested in additional projects where layer 1 could be replaced and perhaps the functions of layer 2 be changed, maybe animation on a three dimensional grid instead of drawing on a two dimensional grid, converting layer 4 to a Class Library was warranted.

This is always more murky than I am making it sound. For example, my rotation schemes are now in a somewhat no-mans land between layer 2 and 3, and I would like to move them to the class library, but the way I embedded the code, it will take some reworking. The point is, the Class library doesn't calculate the size or orientation of the object, which it seems like it should or could... like I said, it doesn't always just pop up as a clear line.

Normally, taking the steps that do seem clear start to bring additional clarity. I tend to be able to write code verbatim and have it work. I can see ahead quite a number of ways. But invariably, if I stay interested in a project and continue to develop it, I will need at least one major rewrite, and sometimes two before I'm happy.

The above discussion was intended to clarify the decision to make a class library, why you would and why you should. There's only one basic decision, though, that the code can be reused successfully, either by you or other developers.

The first step I took was to add a class (DLL) library module to my project. I then copied the code from my drawing module (it was already sorted out and totally parameter driven). If you haven't gathered the code together and made it independent of the local environment, then do that first. That is, the modules shouldn't be accessing local forms or data. The data they do access should be gathered together and probably included in a single structure or two that will reside in the class library. These can be exposed to the user. You don't have to build methods for all the data in the class, but it probably is good form to do that. It gives your module a very professional feel and organizes usage. Also try to type your fields to .NET when possible. If you specify a type with an enumeration, you will get the prompt. A simple example is Boolean. You will be prompted for True or False. If you type System.Drawing.Drawing2d.HatchStyle, you will get 52 enumerations to choose from; System.Color gives 100(?).

Once the code was working, I created a separate class project, and removed the code from my project. While working on debugging, I added my original project to the class project for testing. Once everything was working, I removed the original project and built the DLL separately.

Then add the reference to the original project. Test it and build/publish and test. You should see the DLL deployed with your published build.

The only trick here that I found was to declare your routines as Shared. If they are not Shared, they won't be exposed in the object when you try to access your namespace. You specify your namespace in the properties of the DLL. All pretty painless, actually. You will use NAMESPACE.MODULENAME to access your code.

PS: For an additional professional look and feel, you can add IntelliSense comments to your Class Library. If you type ''' (three single quotes) in the line above your class structure, sub, or routine, an XML outline opens up and you can place your comments in summary, and they will become part of the tooltip when the item is selected from your namespace.