Use assembly from a library which has been created through ILMerge

Question

I have created an assembly package using the tool ILMerge.

There is an assembly (lets call it A ) which is part of that packaged assembly which is going to be used by a other assembly, which is not included in the package (lets call it B ).

Now what I want to do is create a project which references both, the packed assembly and B . Now I would like to do that:

public void Foo()
{
  var obj = new Bar(); // Bar is part of `A`
  var someFactory = new Factory(); // is part of `B`
  someFactory.DoSomething(obj); 
  // compiler error here, which says I need to reference the assembly which contains `Bar`
}

I made sure that the assembly A , which was included into the package and the one referenced by B are the same.

Is there something I`m missing here?

Update with more Context

We have a datamodel project which has lots of dependent projects (I know this is bad in the first place, but its legacy code :-( ) So I would like to merge all these assemblies to one in order to use that data model assembly more easily in multiple solutions.

Answer 1

B references A , not whatever freaky deaky merged assembly you have concocted. It may contain all of the types of A , but it is not A -- assembly identity matters. MyMergedPackage.Bar is not A.Bar , even if they use the exact same type name down to the namespace.

There are multiple possible solutions.

• First and most obviously, you could simply merge B as well. In a typical ILMerge scenario, you merge all assemblies (including the main executable) into one glorious singularity, so you don't have this problem. I'm assuming you have good reasons for not doing this.

• You can simply call your merged assembly A , even though it's A plus lots more. If A has a strong name, you'll need to give that same name (version and all) to your merged assembly. This will keep B happy, which may be enough, but it won't work if you start adding multiple assemblies that want a piece of the whole (you cannot simply copy A around under different names since the types will not be recognized as the same).

• If your version of .NET is sufficiently recent, you can create a new assembly A that only contains a type forward for Bar to your new assembly. This A would simply be a placeholder for the original and only distributed to keep B and assorted friends happy. If you have lots of types this way, this is awkward enough that you want automated help. I'm not immediately aware of any. It also rather defeats the point of merging in most scenarios, since you'll end up with multiple assemblies again anyway.

• At compile time, simply use the separate assemblies. At deployment, replace them all with your merged assembly. Sort things out in code with a handler for AppDomain.AssemblyResolve to fix up the actual type load at run time (simply redirect all unknowns to your merged assembly). This may require some careful tinkering to ensure the event fires before the runtime needs to look up any of the referenced assemblies (static constructors can especially spoil your fun here).

Disclaimer: I have tested exactly none of these solutions; if one doesn't work, please keep me posted so I can fix this answer.