[RESOLVED] [2008] Reference required to assembly...

I'll try to make a long story short and explain my problem quickly.

I have a series of .Net DLLs that are merged and signed using ILMerge. This produces a single DLL which I shall call myasm.dll. This assembly is then added to the GAC.

There is a class in particular loacated in myasm.dll, let's call it myBaseClass.

Another solution has several projects, all of which reference myasm.dll from the GAC without any problems. One of the projects of the solution includes a class, let's call that myDerivedClass, that extends myBaseClass.

Another project in the solution uses myBaseClass from myasm.dll (needless to say that it already has a reference to myasm.dll from the GAC). And here is where the problem begins. When I add a reference to the project that declares myDerivedClass nothing wrong happens. However, when I try to declare a variable of type myDerivedClass I get the error:

Code:

---

Reference required to assembly 'myAsm, Version=1.0.0.0, Culture=neutral, PublicKeyToken=eec2625b41db4608' containing the base class 'myBaseClass'. Add one to your project.

---

The code that generates the error looks like this:

VB Code:

Dim o1 As myBaseClass  '<<< No error here.
Dim o2 As myDerivedClass   '<<< ERROR

This is literally driving me crazy because it makes NO sense at all. As I said, the project that gives out the error already has a reference to myasm.dll. Before anyone asks about it:

1. I can't post code because it's a ton of darn code and it can't be compiled properly without the build program.
2. I have checked that myasm.dll is correctly generated and added to the GAC more than 5 times myself and I had two of my colleagues double check it as well. That means we checked the location of the DLL, the size of the DLL, the public key of the DLL and the manifest of the DLL.
3. I don't have any circular references in the solution that includes the problematic project.
4. I tried removing and re-adding the reference to myasm.dll and all other references.
5. I tried creating a single-project solution, with the same results.
6. Other projects that use myasm.dll build correctly in design time and run correctly in runtime.
7. All references of all the projects of the solution were double-checked for inconsistencies/errors and everything is fine.
8. Most importantly, when I instantiate an object of myDerivedClass using reflection from the problematic project (I remove the code declaration, dynamically load the DLL and run a method invokation) I don't get an error and the object is instantiated correctly. When I create the instance of myDerivedClass and have a look at the assemblies that were loaded in order for that to happen, there is nothing curious there (like a supporting DLL that has been loaded from another location that the one that I intended).

If anyone has any ideas, knows a workaround or solution I would love to hear some feedback.

What happens if you use the original DLLs instead of the one merged DLL? I'm not saying that that is a final solution but I'd be interested to know the answer.

It works that way. As you said, it's not the answer - my sole reason of using ILMerge was to reduce the number of DLLs from ~30 to an easily manageable 1.

I'm not meaning to be a smart ass, but isn't that a ILMerge issue? Have you contacted their support?

You're not being a smart ass but I wasn't sure that it's an ILMerge issue.

Found the problem. All of the DLLs that are assembled via ILMerge were signed except one (by mistake). ILMerge signed the produced assembly with the same key that was used to sign the individual DLLs. Once that DLL was also signed before merging, the problem went away.

My guess is that the .Net architecture examined the evidence of the merged assembly and found that some piece of the code in there provided something different than expected. If that's the case, the error message provided by VS wasn't helpful.

Thanks jmcilhinney & wild_bill for taking the time to help me out.