TargetInvocationException makes no sense

  • Thread starter Thread starter dudi
  • Start date Start date
D

dudi

Hi, very puzzling...
I have one perfectly working solution, in which I use a a.dll which has a
class A. that class loads data from
the database and for each row deserialize the cell into class A1. works
great.
I made a new solution, I linked to the same a.dll, and In a new project in
this new solution I call the same function in a.dll that will load the
datatable and for each row deserialize the info into class A1.
however, this time in the line of code that calls the deserialize I get:
An unhandled exception of type
'System.Reflection.TargetInvocationException' occurred in mscorlib.dll
Additional information: Exception has been thrown by the target of an
invocation.

I tried several thinks, first I checked I am using in both solution vs.NET
2003 and not 2002 in one of them by mistake, I tried copying the code that
does the deserialization into the new solution instead of linking to a.dll,
I also tried adding the a.dll project to the new solution (instead of just
adding a reference to the dll)... nothing works. I get that exception and I
can not make any sense of it!
the only intuition I have is that it might be because of security or name
space issues that deserialization is known to be sensitive to, but I can not
find any path to the light. any ideas?

some code follows:
Dim dt As DataTable = _dbmaster.getDataTable(_sqlSel)
Dim row As DataRow
Dim bf As New Runtime.Serialization.Formatters.Binary.BinaryFormatter
Dim topic As iProgramTopic.Topic
For Each row In dt.Rows
Dim byts As Byte() = CType(row("srlz"), Byte())
Dim ms As New IO.MemoryStream(byts)
topic = CType(bf.Deserialize(ms), iProgramTopic.Topic)
'------------EXCEPTION!!!!!---------
_ht.Add(topic.topicId.strKey, topic)
Next
regards.
 
Is all of this being run on a local machine, or from an intranet location.
It could be caused by the types failing verification. This is commonly
caused by developing the code on the local machine where type verification
is not done, then running from the local intranet zone where type
verification is done.

Another thing to look into is whether the type you're deserializing into is
EXACTLY the same type which was serialized.


--------------------
 
Is all of this being run on a local machine, or from an intranet location.
well, both are being run from the VS, and the projects and all files are
local. the only different is that in each case the solution is on a
different mapped drive. which I do not think should matter.
It could be caused by the types failing verification. This is commonly
caused by developing the code on the local machine where type verification
is not done, then running from the local intranet zone where type
verification is done.
Click to expand...
well, in both cases, it is the same code, same class, just linked from
different driver project. both are run from same computer just different
mapped drives.

Another thing to look into is whether the type you're deserializing into is
EXACTLY the same type which was serialized.
Click to expand...
well if it wasn't, then both applications should fail right? not only one.

still stuck on this (-:
regards.
 
OK, found the problem. The problem is of course not at all related to
Serialization... it is completely custom problem related to uninitialized
data.
however, what the general public can learn from this is that this
TargetInvocationException is very uninformative, and that is why I could
zero in on the problem.
however, when I executed the program NOT from within the debugger, I got the
exception box where I could click on "Details", and I actually got more
information there (a better stack and more informative error msg) which lead
me to the problem: here I also got the NullReferenceException msg and the
stack location which I did not get while running in the debugger:
System.Reflection.TargetInvocationException: Exception has been thrown by
the target of an invocation. ---> System.NullReferenceException: Object
reference not set to an instance of an object.

thanks for the help.
regards.
 
Hi,

This exception is usually thrown when a remoting call is made across
application domain boundaries. It is not that meaningless if you know where
to look for details. The key property is InnerException - you should examine
this one to obtain the real exception occured. Chances are this property
will contain another TargetInvocationException instance - so you should
continue digging into the InnerException chain until you've found something
meaningful.
 
wouldn't it be nice if the debugger's exception message allowed my to
dig into that chain?
 
Yeah it would be a nice feature so you might wish to suggest it to the
Visual Studio team.
One can browse the chain by adding the exception variable to the Watch
window and expanding the InnerException nodes.
 
Uri Dor said:
wouldn't it be nice if the debugger's exception message allowed my to
dig into that chain?
Click to expand...

Try opening a watch window on the exception object's ToString method. That
should give you then entire stack trace, including that of inner exceptions.
It's not the most convenient format but the data is there.
 
Back
Top