Creating and Using C# DLLs

Environment: C#

Introduction

In this article, I would like to explain how to create and use DLLs in C Sharp. Before writing code, we will examine some basics of a DLL in the .NET framework; for example, how it's loaded in the process address space, how CLR is initialized, and the mechanism behind the screen. First, we will talk about MSCorEE.dll; you will find this guy in the %windir%\system32\ directory. MSCorEE.dll stands for Microsoft Component object runtime Execution Engine. The existence of this file tells you that you have installed the .NET framework in your system. This DLL is responsible for initializing the CLR.

Whenever you create an assembly, the compiler/linker emits the following 6-byte x86 stub function into the PE file's .text section:

JMP _CorExeMain for Exe or JMP _CorDllMain for Dll.

Figure 1 shows the Portable Executable (PE) file format. This stub function is implemented inside the MSCorEE.dll. So, this dll must be referenced somewhere in the PE file. Yes, your guess is right; it's referenced in the .idata section of the PE file. The .idata section is used to refer import libraries for assembly.

Figure 1—The PE file format.

We have given all the hints and clues to the Windows loader, so here we go.... When the managed assembly file is invoked, the Windows loader completes the following steps:

  1. Loads the PE file, parses the .idata section, and loads MSCorEE.dll (if it's not already loaded) into the process's address space.
  2. Takes the address of _CorExeMain in the case of an Exe assembly, or _CorDllMain in the case of a DLL assembly function, inside the MSCoreEE.dll.
  3. Using the address from Step 2, the Windows loader fixes the stub function JMP instruction (from the .text section PE).

At this point, the process's primary thread starts executing the stub function; that is, it jumps to _CorExeMain for Exe or _CorDllMain for Dll in the MSCorEE.dll. The _CorExeMain or _CorDllMain initializes the CLR and looks for a managed entry point from the assembly's CLR header and starts executting. Here the IL code for the method is compiled into native CPU instructions and the CLR jumps to native code. That's it; the managed applications code is running.

The framework differentiates between managed executive and managed DLL files because of the stub function stored in the .text section of the PE file. For Exe, the stub function is JMP _CorExeMain and for Dll the stub function is JMP _CorDllMain. The Windows loader differentiates this function and fixes the corresponding address from the MSCorEE.dll.

I think now we know how a managed exe/dll loads in the process address space and how CLR gets initialized. Okay, time for coding. Here we develop a small DLL and a test container for that. This DLL will export three functions, each from one class in a namespace.

Open a new C# WindowsApplication project in Visual Studio .NET. Name the Project MathFunctions.

Add the following three classes to this project. Name them something like AddClass.cs, MultiClass.cs, and FactorialClass.cs.

Listing 1. AddClass.cs

using System;

namespace MathFunctions
{
  public class AddClass
  {
    public static int Add(int a, ant b)
    {
      return (a+b);
    }
  }
}

Listing 2. MultiClass.cs

using System;

namespace MathFunctions
{
  public class MultiClass
  {
    public static int Multiply(int a, int b)
    {
      return (a*b);
    }
  }
}

Listing 3. FactorialClass.cs

namespace MathFunctions
{
  public class FactorialClass
  {
    public static int Factorial(int i)
    {
      return((i <= 1) ? 1 : (i * Factorial(i-1)));
    }

  }
}

Our idea is to export AddClass::Add, MultiClass:: Multiply, and FactorialClass::Factorial from the namespace MathFunctions. That's it; we're finished coding.

Go to the command line and type the following.

CSC /target:library /out:MyFunctions.dll AddClass.cs
     MultiClass.cs FactorialClass.cs

Go to the command line option /target:library and ask the C Sharp Compiler/Linker to output a DLL instead of an EXE. It's possible to have a different name for the DLL; for example, /out:MyFunctions.dll directs the compiler to output the DLL with the name MyFunctionsLib; otherwise, it will take the default name from the first .cs file. Here, it's AddClass.dll.

Now comes the test container for this DLL. Create a new WindowsApplication project by right-clicking the solution in the Solution Explorer pane. Name it DllTestApp.

Add the following line to the Using section.

using MathFunctions;

Add the following code to the click of button1.

private void button1_Click(object sender, System.EventArgs e)
{
int add = AddClass.Add(125,125);
  int mul = MultiClass.Multiply(25,25);
  int fac = FactorialClass.Factorial(5);

  string str = "Addition result = " + add.ToString() + "\n"
       + "Multiplication result = " + mul.ToString() + "\n"
       + "Factorial result = " + fac.ToString();

  MessageBox.Show(str, "MyDllTestDialog");

}

To refer to the DLL in our project, right-click the project's reference and click Add Reference. This displays tabbed panes that list the various types of components and projects you can browse. On the .NET tab, click the Brows button and browse for the DLL to which you want to refer (here, MyFunctions.dll), and click OK.

This solves the problem of DLL hell or version problems. Any change in the DLL will be reflected as we refer in this project.

Any suggestions and criticisms, please drop an e-mail to rishibala@hotmail.com.

Downloads

Download demo project - 40 Kb