1 using System;

    2 

    3 public class HelloWorld

    4 {

    5     public static void Main()

    6     {

    7         Console.WriteLine("HelloWorld::Main() has begun.");

    8 

    9         // say hello in this domain

   10         new HelloWorldAux().HelloWorld();

   11 

   12         // create a new domain and say hello over there

   13         AppDomain newDomain = AppDomain.CreateDomain("Second AppDomain");

   14         HelloWorldAux remote = newDomain.CreateInstanceAndUnwrap(typeof(HelloWorldAux).Assembly.GetName().Name, typeof(HelloWorldAux).Name) as HelloWorldAux;

   15         remote.HelloWorld();

   16         return;

   17     }

   18 }

   19 

   20 public class HelloWorldAux : MarshalByRefObject

   21 {

   22     public void HelloWorld()

   23     {

   24         AppDomainManager currentManager = AppDomain.CurrentDomain.DomainManager;

   25         if (currentManager == null)

   26             Console.WriteLine("No Managed AppDomainManager");

   27         else

   28             Console.WriteLine("AppDomainManager: " + currentManager.GetType().Name);

   29 

   30         Console.WriteLine("Hola, mundo");

   31     }

   32 }

   33 

Figure 6.

Just as before, we must create a class in anticipation of launching it in a new AppDomain. In this case, the class is called HelloWorldAux.

Before we can test our application, we must find some way of telling the CLR to use our AppDomainManager. Ultimately, we will want to program our unmanaged host to specify the manager and obtain a reference to it. Alternatively, we could change entries in the Windows system registry so that the CLR will always load our custom manager. Obviously, this is not the wisesst choice for the early stages of testing. The last alternative is to set environment variables in a command console. Any CLR loaded up by a process launched from that window will use our custom AppDomainManager. Others will not.

A batch file to set the environment variables is included in the zipped example files. If you prefer typing it yourself, it looks like this:

SET APPDOMAIN_MANAGER_ASM=AppDomainManager02,Version=1.0.0.0,Culture=neutral, PublicKeyToken=931530800db9d27a,processorArchitecture=MSIL
SET APPDOMAIN_MANAGER_TYPE=AppDomainManager02.AppDomainManagerTest

Obviously, each of the SET commands must be on a single line. The value for the public key presumes that you use the strong key file included with the project files. If you create your own key file, you will need to substitute your new public key.

By default, the CLR will not probe for the AppDomainManager assembly. This means that there are only two choices. The assembly must be located in the same folder as the exe file, or the assembly must be placed into the GAC.

After you copy HelloWorld.exe and AppDomainManager02.dll into the desired folder, we are ready to test. Open a command prompt window and run the SET statements above or run the envvars.bat batch file. Then type "HelloWorld" and hit <enter> like you normally would. You should see something like this:

Figure 7.

Now we need to understand exactly what we are seeing. After Windows recognizes HelloWorld for a managed executable, it loads the CLR, which creates a default AppDomain. The CLR then creates an instance of our AppDomainManager for that new AppDomain, and we see the constructor in our object report its execution in red. The CLR then makes several requests for HostSecurityManager objects; we see these in yellow. The CLR then loads and runs HelloWorld.exe. We see the execution of Main(). Main() the reports the AppDomainManager for its AppDomain, the default AppDomain.

The code in Main() then requests the creation of a new AppDomain by calling the CreateDomain() method of the AppDomain class. Note that Main() is not calling our AppDomainManager. The CLR calls the CreateDomain method of the AppDomainManager in the default AppDomain, giving it a chance to specify the characteristics of the new AppDomain about to be created. Indeed, as mentioned our custom AppDomainManager might even decide not to grant the request for a new AppDomain, and return a reference to an appropriate existing AppDomain instead. The CreateDomain() method reports its execution in green in the console. Only after this, if our managed code requests it, does the CLR create a new AppDomain and load into it a new instance of our AppDomainManager class. We see the instantiation of this class in the red report in the console. Once again, the CLR requests HostSecurityManager objects. At this point, the new AppDomain is ready for use and the HelloWorld() method executes in the new AppDomain. It is worth nothing that the HelloWorldAux class must be loaded in both AppDomains, or there would be no way for the default AppDomain to create a proxy to run the code in the second domain. We may ultimately wish to consider alternatives to this duplication.

Congratulations on getting this code running. In the next installment, we will add some security features, making a real custom AppDomainManager, and integrate this into our unmanged host application.

Source Code

The source code for all examples can be found here .

About the author:

Dan Buskirk had been a research scientist for many years when he left the university labs to participate in a startup venture to design and build databases for medical science. Since that time he has managed a consulting practice specializing in database design and development. Dan balances this with training on Microsoft SQL Server, Microsoft Analysis Services, and .NET programming. His interests include mathematical methods for data mining and computing methods for advanced data categorization on Windows clusters.