There may be times when you wish to temporarily load a .NET assembly to inspect it, but you don’t want the assembly to remain in your program’s memory taking up resources.  Unfortunately, once your program loads an assembly, there is no way to unload it.  The best way is to create a separate AppDomain, load the assembly into that AppDomain, then unload the AppDomain when you are finished.

The following sample code loads a .NET assembly from disk, displays the name of every type defined in the assembly, then unloads the assembly:

AppDomain appDomain = null; 
try 
{ 
    string path = @"C:myAssembly.dll"; 
    byte[] buffer = File.ReadAllBytes( path ); 

    appDomain = AppDomain.CreateDomain( "Test" ); 
    Assembly assm = appDomain.Load( buffer ); 

    Type[] types = assm.GetTypes(); 
    foreach (Type type in types) 
    { 
        Console.WriteLine( type.FullName ); 
    } 
} 
catch (Exception ex) 
{ 
    Console.WriteLine( ex.Message ); 
} 
finally 
{ 
    if (appDomain != null) 
        AppDomain.Unload( appDomain ); 
}

Creating C# objects at run-time is easy. Just call the Activator.CreateInstance method.

For example, to create the same type of object as the current object using its default constructor:

Activator.CreateInstance( this.GetType() );

Read the rest of this entry »

Reflection is a handy mechanism in .NET that enables you to obtain class information, get and set properties, and invoke methods entirely at run-time. Reflection can also provide information about the object and method that called a particular method. This can be useful for debug and trace purposes.

Read the rest of this entry »

The version of .NET against which you compile an application or assembly may not be the same version of .NET on which the application is currently running. A .NET application should always be able to run on the same or newer version of .NET against which it was compiled.

This is because .NET is backward compatible. This means that an application compiled on .NET v1.1 should run OK on .NET v2.0 and v3.0. But an application compiled on .NET v2.0 will not run on .NET v1.1.

Read the rest of this entry »

This multi-part article answers common questions about assemblies, the basic building blocks of .NET applications. This Part 4 covers shared assemblies and the Global Assembly Cache.

Read the rest of this entry »

A .NET assembly is “signed” if the developer compiled the assembly with the private key of a digital signature. When the system later loads the assembly, it verifies the assembly with the corresponding public key. Occasionally you may need to determine whether an assembly you have loaded has been signed.

Read the rest of this entry »

This multi-part article answers common questions about assemblies, the basic building blocks of .NET applications. This Part 3 discusses assembly security using strong names, signing and public-private key pairs.

Read the rest of this entry »

This multi-part article answers common questions about assemblies, the basic building blocks of .NET applications. This Part 2 discusses assembly attributes.

Read the rest of this entry »

Frequently asked questions, some assembly required.

This multi-part article answers common questions about assemblies–the basic building blocks of .NET applications. Some developers may never need to understand assemblies. But if you create shared components, use DLLs or deliver a suite of applications, then it’s essential to understand what .NET assemblies are and how they work.

Read the rest of this entry »

When you attempt to add an assembly reference to a Visual Studio project, the Add Reference dialog appears with a list of registered global assemblies in the .NET tab:

Add Your Assembly to Visual Studio

Unfortunately, adding your assembly to the Global Assembly Cache (GAC) does NOT make it automatically appear in the Visual Studio list of installed assemblies; you must add your assembly manually as follows:

Read the rest of this entry »