Embedding assemblies inside another assembly

Question

If you create a class library that uses things from other assemblies, is it possible to embed those other assemblies inside the class library as some kind of resource?

I.e. instead of having MyAssembly.dll, SomeAssembly1.dll and SomeAssembly2.dll sitting on the file system, those other two files get bundled in to MyAssembly.dll and are usable in its code.

---

I'm also a little confused about why .NET assemblies are .dll files. Didn't this format exist before .NET? Are all .NET assemblies DLLs, but not all DLLs are .NET assemblies? Why do they use the same file format and/or file extension?

Solution 1

Take a look at ILMerge for merging assemblies.

I'm also a little confused about why .NET assemblies are .dll files. Didn't this format exist before .NET?

Yes.

Are all .NET assemblies DLLs,

Either DLLs or EXE normally - but can also be netmodule.

but not all DLLs are .NET assemblies?

Correct.

Why do they use the same file format and/or file extension?

Why should it be any different - it serves the same purpose!

Solution 2

ILMerge does merge assemblies, which is nice, but sometimes not quite what you want. For example, when the assembly in question is a strongly-named assembly, and you don't have the key for it, then you cannot do ILMerge without breaking that signature. Which means you have to deploy multiple assemblies.

As an alternative to ilmerge, you can embed one or more assemblies as resources into your exe or DLL. Then, at runtime, when the assemblies are being loaded, you can extract the embedded assembly programmatically, and load and run it. It sounds tricky but there's just a little bit of boilerplate code.

To do it, embed an assembly, just as you would embed any other resource (image, translation file, data, etc). Then, set up an AssemblyResolver that gets called at runtime. It should be set up in the static constructor of the startup class. The code is very simple.

    static NameOfStartupClassHere()
    {
        AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(Resolver);
    }

    static System.Reflection.Assembly Resolver(object sender, ResolveEventArgs args)
    {
        Assembly a1 = Assembly.GetExecutingAssembly();
        Stream s = a1.GetManifestResourceStream(args.Name);
        byte[] block = new byte[s.Length];
        s.Read(block, 0, block.Length);
        Assembly a2 = Assembly.Load(block);
        return a2;
    }

The Name property on the ResolveEventArgs parameter is the name of the assembly to be resolved. This name refers to the resource, not to the filename. If you embed the file named "MyAssembly.dll", and call the embedded resource "Foo", then the name you want here is "Foo". But that would be confusing, so I suggest using the filename of the assembly for the name of the resource. If you have embedded and named your assembly properly, you can just call GetManifestResourceStream() with the assembly name and load the assembly that way. Very simple.

This works with multiple assemblies, just as nicely as with a single embedded assembly.

In a real app you're gonna want better error handling in that routine - like what if there is no stream by the given name? What happens if the Read fails? etc. But that's left for you to do.

In the rest of the application code, you use types from the assembly as normal.

When you build the app, you need to add a reference to the assembly in question, as you would normally. If you use the command-line tools, use the /r option in csc.exe; if you use Visual Studio, you'll need to "Add Reference..." in the popup menu on the project.

At runtime, assembly version-checking and verification works as usual.

The only difference is in distribution. When you deploy or distribute your app, you need not distribute the DLL for the embedded (and referenced) assembly. Just deploy the main assembly; there's no need to distribute the other assemblies because they're embedded into the main DLL or EXE.

Solution 3

You can embed an assembly (or any file, actually) as a resource (and then use the ResourceManager class to access them), but if you just want to combine assemblies, you're better off using a tool like ILMerge.

EXE and DLL files are Windows portable executables, which are generic enough to accomodate future types of code, including any .NET code (they can also run in DOS but only display a message saying that they're not supposed to run in DOS). They include instructions to fire up the .NET runtime if it isn't already running. It's also possible for a single assembly to span across multiple files, though this is hardly ever the case.

Solution 4

Note ILMerge doesn't work with embedded resources like XAML, so WPF apps etc will need to use Cheeso's method.

Solution 5

There's also the mkbundle utility offered by the Mono project

View more solutions

Comments

[Mark Cidade]

.netmodule is for Modules, which are parts of an assembly (e.g., built with different language compilers) but aren't standalone assemblies.

[devios1]

Wow I never thought of doing that... to be honest I'm surprised it works.

[mheyman]

The GetManifestResourceStream(args.Name) probably should be GetManifestResourceStream(string.Format("{0}.lib.{1}.dll", typeof(Foo).Namespace, new AssemblyName(args.Name).Name)) or GetManifestResourceStream(string.Format("{0}.{1}.dll", typeof(Foo).Namespace, new AssemblyName(args.Name).Name)). I don't know the reasons why but I've has to use either of these.

[Cheeso]

@mheyman - re: * I don't know the reasons why...*. it just depends on how you name the embedded resources when you compile the thing. You can use this to diagnose: cheeso.members.winisp.net/… (A tool that displays the names of the embedded resources in an assembly)

[Christoph]

How does that work if you have a solution with multiple projects and you want to include project A into project B. You can not include a project as resource I suppose. You would have to point to either the output path of the project (either Debug or Release) which again makes things more complicated. Is there an easy solution for such a scenario?

[Omegacron]

I keep getting an error on my byte array - the dreaded "Object reference not set to an instance of an object" one. I'm guessing because the array is null?

[CodeFox]

For the records: This only works for mono applications as also bundles the mono runtime. From the docs: Bundles merge your application, the libraries it uses and the Mono runtime into a single executable image. You can think of bundles as “statically linking mono” into your application.

[jtate]

I'm assuming that code snippet should be put in a void Main(args) function for an exe, but where do we put this code if we're creating a class library?