writing event handlers with argument types defined in reflected dll's possible ?

  • Thread starter Thread starter Stephen Ahn
  • Start date Start date
S

Stephen Ahn

Suppose I have object O with an event E that are
defined in an assembly M that I am referencing in
my code via reflection. M also defines object A which
is an argument to E.

At compile-time, how can I write a function that meets
the signature for event E, when the compiler
doesn't know about A ?

I can solve this problem using Delegate.CreateDelegate
etc if the type of E's arguments are known at
compile time, but what about when there is an
unknown type ?

TIA,
Stephen
 
U¿ytkownik "Stephen Ahn said:
Suppose I have object O with an event E that are
defined in an assembly M that I am referencing in
my code via reflection. M also defines object A which
is an argument to E.

At compile-time, how can I write a function that meets
the signature for event E, when the compiler
doesn't know about A ?

I can solve this problem using Delegate.CreateDelegate
etc if the type of E's arguments are known at
compile time, but what about when there is an
unknown type ?
Click to expand...

You could read the E's signature at run-time, create a handler code
dynamically (as string), compile it to memory (adding a reference to M) and
create a delegate handler from compiled method.

But since you do not know anything about the delegate's argument type, how
would you like to make use of it?

regards,
Wiktor Zychla
 
Wiktor Zychla said:
You could read the E's signature at run-time, create a handler code
dynamically (as string), compile it to memory (adding a reference to M)
and create a delegate handler from compiled method.

But since you do not know anything about the delegate's argument type, how
would you like to make use of it?
Click to expand...

Thanks for your response.

Well, the argument type is a simple class with just a few public properties.
The types of the properties are standard dotnet types.
Since we know the names of the properties, I was thinking
they could be referenced via reflection.

We had to use reflection to access the third party dll, because it
is not signed, and not in the GAC. The dlls are also not in a
subdirectory of our app.

Maybe we are approaching this the wrong way (?)

Stephen.
 
Back
Top