Building a .NET library
In this chapter I will build a library which will be used in other .NET
projects. After a brief introduction to the contents of the library I will discuss the
deployment of libraries.
Writing the code
Code to be used in other projects is housed in a class library, this is
a DLL in the .NET flavor. In this dll there is more than just plain code, it also
contains (meta)data on things like author, version, types defined as well as resources
used. The whole of metadata, code and resources is named an assembly.
In Visual Studio.NET I will create a new class library by choosing File | New |
Project | Class Library. As a name I will take GekkoLibrary. The first
unit will contain the root classes. The
namespace of this unit is plain Gekko. The source code itself is in the demo
project and is commented. I will not dive to deep in the C# syntax and
constructs used, to learn more about that I suggest you read Inside
C#. The main goal of the Gekko root is to construct a class to manage a list of
of objects which can be identified by name, something like a tStringList in Delphi.
A full explanation can be found in the full
story on automation.
The second unit contains all base classes for automation.
The namespace for this unit is Gekko.Automation. This sourcecode is in
the demo project as well and is commented too. It uses the root classes of the Gekko
namespace. The main goal is to provide a framework to build connectable automation servers
in .NET. Again a full explanation can be found in the full
story
The class viewer of VS does give a nice overview of the Gekko library
The assemblyinfo
In every project you will find an unit assemblyinfo.cs. Here I can
fill in attributes to describe my GekkoLibrary assembly
[assembly: AssemblyTitle("the Gekko Automation Library")]
All these attribute values will show in property inspectors and in reflection.
Before I will deploy the assembly I have to think about versioning. There is
a very big chance that there will be new versions of the library. How
does the user of my library know which version of the Gekko namespace is
being used ? Or how does the user know it is the original Gekko namespace and
not some evil code operating under the same name(-space) and doing some very bad
unintended things ? .NET has a sophisticated mechanism for versioning and
authentication built in. To join in that I have to create a shared (also called
strong) name for the assembly and sign my assembly with this name.
The commandline tool SN.exe found in the directory Program Files\Microsoft
Visual Studio .NET\FrameworkSDK\BIN will create a globally unique name and
write this to a keyfile.
sn -k GekkoLibrary.key
This keyfile is used in the assemblyinfo unit
[assembly: AssemblyKeyFile("GekkoLibrary.key")]
Now my assembly is signed with an unique name (just a huge sequence of numbers and
letters), can be identified and is ready to be deployed.
Deploying the assembly to the runtime environment
A signed assembly can be made sharable by adding it to the global assembly
cache (gac). At very first sight this gac seems a
plain subdirectory of \WINNT, named assembly.
When you take a closer look, the directory displays custom column
headers like "Assembly name" and "version". It
is not the normal Windows explorer but the gac-viewer we are seeing at work here. The simplest way to deploy an
assembly is just dropping it on this viewer's pane.
When you browse the "WINNT\assembly" directory using the command prompt
it appears to be filled
with a whole tree of subdirectories. To add an assembly from the command prompt to the right place there is the command line utility GacUtil.exe.
It can also be found in the directory Program Files\Microsoft Visual Studio
.NET\FrameworkSDK\BIN and is used as follows:
gacutil -i GekkoLibrary.dll
After which my library with the Gekko namespace can be used by other .NET
projects. Another alternative to deploy is using the Microsoft Installer.
Don't overestimate the gac
The gac does look very nice but it is not intended as the new windows\System32
directory, which was the dumping place for libraries in the pre .NET days. The recommendations for
deploying a .NET application is to store everything, including the libraries, in
the applications private directory. This could lead to some redundancy of files
on disk but the small size of .NET assemblies and the large capacity of today's
disk drives will not often make this a point. Besides that not every user has
the necessary rights to add assemblies to the gac.
When you deploy your assembly to a private directory it still does make sense
to sign your assemblies with a keyfile. The .NET security check will always
check the integrity of signed code being loaded.
The gac is not available
to the designtime environment. Any project which wishes to use an assembly has
to make a reference to an explicit file containing an explicit version of the
assembly itself. The metadata in that assembly will provide all the info the VS IDE
needs to view the classes contained.
Where are we ?
Assemblies house code and metadata which inform the potential user of the
code. For the sake of versioning and security assemblies should be signed (given
a strong name) using a keyfile.
.NET has a global assembly cache where signed sharable assemblies are stored.
After signing the assembly it can be published there. The easiest way to publish
is to drop the assembly on the gac (global assembly cache) viewer. The
number of versions of the assembly in the cache will grow with every new
publish. The user of an assembly will have a choice of available versions. The
.NET recommendations favor deploying an assembly to the private directory of an
application.
What's next
|