Deriving a sealed class

[shawnz]

Is there any way to either derive a sealed class, or access private
members of a sealed class? Either that, or is there a way to run
internal methods in a sealed class outside the current assembly? I
don't mind if the solution is hackish, the dll i'm writing is already
full of code hacks. =p

[Jon Skeet [C# MVP]]

shawnz <zi*******@gmail.com> wrote:

Is there any way to either derive a sealed class, or access private
members of a sealed class? Either that, or is there a way to run
internal methods in a sealed class outside the current assembly? I
don't mind if the solution is hackish, the dll i'm writing is already
full of code hacks. =p

You can't derive from a sealed class, but you can access members you're
not supposed to using reflection *if* you've got sufficient
permissions.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[shawnz]

Thanks for the advice! I didn't think to use reflection on them... This
will work on types outside the current assembly (in a reference) right?
Also, could you give me a function to point me in the right direction
doc-wise?

[justncase80]

Probably the best thing to do instead is to take a hard look at your
design and refactor it until you get rid of the hacks. If your code is
already "full of hacks" you're just digging your grave deeper.

~justin

shawnz wrote:

Thanks for the advice! I didn't think to use reflection on them... This
will work on types outside the current assembly (in a reference) right?
Also, could you give me a function to point me in the right direction
doc-wise?

[shawnz]

To be honest, the reason behind this is i'm trying to get around the
Internet wlm add-in sandbox without patching MessengerClient.dll. So,
using dodgy code hacks is almost my only line of defense before I
resort to doing something that can't be distributed. :p

justncase80 wrote:

Probably the best thing to do instead is to take a hard look at your
design and refactor it until you get rid of the hacks. If your code is
already "full of hacks" you're just digging your grave deeper.

~justin

shawnz wrote:

Thanks for the advice! I didn't think to use reflection on them... This
will work on types outside the current assembly (in a reference) right?
Also, could you give me a function to point me in the right direction
doc-wise?

[Peter Bromberg [C# MVP]]

Maybe DotMsn can help you:

http://www.xihsolutions.net/dotmsn/

Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"shawnz" wrote:

To be honest, the reason behind this is i'm trying to get around the
Internet wlm add-in sandbox without patching MessengerClient.dll. So,
using dodgy code hacks is almost my only line of defense before I
resort to doing something that can't be distributed. :p

justncase80 wrote:

Probably the best thing to do instead is to take a hard look at your
design and refactor it until you get rid of the hacks. If your code is
already "full of hacks" you're just digging your grave deeper.

~justin

shawnz wrote:

Thanks for the advice! I didn't think to use reflection on them... This
will work on types outside the current assembly (in a reference) right?
Also, could you give me a function to point me in the right direction
doc-wise?

[Ian Semmel]

You could put an instance of the class in your class and expose all the
properties and then either call the sealed class or do your own stuff.

shawnz wrote:

Is there any way to either derive a sealed class, or access private
members of a sealed class? Either that, or is there a way to run
internal methods in a sealed class outside the current assembly? I
don't mind if the solution is hackish, the dll i'm writing is already
full of code hacks. =p

[Mike Schilling]

"shawnz" <zi*******@gmail.com> wrote in message
news:11**********************@m38g2000cwc.googlegr oups.com...

Thanks for the advice! I didn't think to use reflection on them... This
will work on types outside the current assembly (in a reference) right?
Yes.
Also, could you give me a function to point me in the right direction
doc-wise?

Look at System.Reflection.FieldInfo and System.Reflection.MethodInfo.

[shawnz]

shawnz wrote:

Thanks for the advice! I didn't think to use reflection on them... This
will work on types outside the current assembly (in a reference) right?
Also, could you give me a function to point me in the right direction
doc-wise?

Also, another quick question, I realized I can't set the variables
myself because their types depend on to many other internal things. Is
there a way to just call the internal "Startup()" function from my dll?
Could I possibly inject a function into my instance of the class and
run that to run "Startup()"?