Free-ebooks-library - Bahar Ali Khan

if (!File.Exists (path)) return null; // Sanity check
return Assembly.LoadFrom (path); // Load it up!
}
}
class Program
{
internal static void Go()
{
// Now we can reference types defined in c:\ExtraAssemblies
}
}
It’s vitally important in this example not to reference types in
c:\ExtraAssemblies directly from the Loader class (e.g., as fields),
because the CLR would then attempt to resolve the type before
hitting Main().
In this example, we could use either LoadFrom or LoadFile. In either case, the CLR
verifies that the assembly that we hand it has the exact identity it requested. This
maintains the integrity of strongly named references.
In Chapter 24, we describe another approach that can be used when creating new
application domains. This involves setting the application domain’s PrivateBin
Path to include the directories containing the additional assemblies—extending the
standard assembly probing locations. A limitation of this is that the additional directories
must all be below the application base directory.
Packing a Single-File Executable
Suppose you’ve written an application comprising 10 assemblies: 1 main executable
file, plus 9 DLLs. Although such granularity can be great for design and debugging,
it’s also good to be able to pack the whole thing into a single “click and run”
executable—without demanding the user perform some setup or file extraction ritual.
You can accomplish this by including the compiled assembly DLLs in the main
executable project as embedded resources, and then writing an AssemblyResolve
event handler to load their binary images on demand. Here’s how it’s done:
using System;
using System.IO;
using System.Reflection;
using System.Collections.Generic;
public class Loader
{
static Dictionary _libs
= new Dictionary ();
static void Main()
{
676 | Chapter 17: Assemblies