[VS2005, C#, MSMQ] TypeLoadException driving me insane

[Jeff Johnson]

I'm not sure what's causing this, hence the cross-post.

I have an assembly, let's call it Classes.dll, which contains a few classes
that are used by other assemblies.

I have a WinForms program with a UI, business, and data layer (i.e., an .EXE
and two supporting .DLLs). The business layer needs to send a message to a
message queue. It uses one of the classes from Classes.dll as the body of
the message. Code looks like this (my very small business layer is currently
just a static class):

public static void SubmitJob(PackageEntity package, ScheduleEntry schedule)
{
// some code
AddImmediateQueueEntry(instanceId);
// more code
}

private static int AddImmediateQueueEntry(Guid instanceId)
{
QueueActivityRequest addRequest = QueueActivityRequest.CreateAddRequest(
instanceId,
_taskExecutorId,
DateTime.Now,
_applicationId,
false);
// more code
}

QueueActivityRequest is the class in question. This line is causing the
TypeLoadException error mentioned in the subject. Interestingly, when the
IDE breaks, it breaks on the calling line (AddImmediateQueueEntry above) as
opposed to the line where the object is being set, EVEN IF I go into Debug |
Exceptions and tell the debugger to break when CLR errors are thrown. I even
moved the code out of the AddImmediateQueueEntry function and into SubmitJob
and at that point the code broke at the call to SubmitJob!

I have cleaned the project. I have rebooted. I have removed the reference to
the assembly and re-added it. I have made sure that the assembly is copied
locally. This error continues to happen.

As a test I created a simple console app, referenced Classes.dll, and
instantiated a QueueActivityRequest object (using the same static function I
used above) and it worked perfectly.

Any idea why my business layer hates this class? Karma, perhaps? Any
suggestions are welcome.

 

[Frank Boyne]

Any suggestions are welcome.

It's a bit of a fishing expedition, but how about wrapping the fooending
call in a try-catch block and the nddd WriteLine (ex) to the catch block
(where ex is your exception variable). That should give you the
exception message, the exception stack history and anything else the
exception implementor thought worth printing out. Post that to the ng
and maybe the extra data will jog someone's thoughts.

 

[Frank Boyne]

It's a bit of a fishing expedition, but how about wrapping the
fooending call

or even 'offending call'.

 

[Scot T Brennecke]

Have you tried Suzanne Cook's suggestions, especially in the use of the Fusion log?
http://blogs.msdn.com/suzcook/archive/2004/02/13/72728.aspx

 

[Jeff Johnson]

I'm not sure what's causing this, hence the cross-post.

Hey everyone, the problem seems to have been due to XML serialization and
MDAs. I had MDAs set to break on thrown exceptions, and after moving the
classes to the same assembly I started getting BindingFailure exceptions.
Setting the MDA to break only on unhandled exceptions cleared me up, at
least in that respect. I haven't gone all the way back to accessing the
classes from a satellite assembly, but at least it's working fine with
internal classes.