By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,110 Members | 1,606 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,110 IT Pros & Developers. It's quick & easy.

Reflection and access-modifiers

P: n/a
Hi all,

Using reflection, I can invoke/call private methods of an object.

is this intended?
if yes, why? in what scenario (example would be good) should I be givven the
option to use something that was declared private (not public) and not mine
to use? seems to me this is somewhat malicious...
if not.... well....

Thanx,
Picho
Nov 16 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Yes its intended - its how the System.Runtime.Serialization infrastructure works for example

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi all,

Using reflection, I can invoke/call private methods of an object.

is this intended?
if yes, why? in what scenario (example would be good) should I be givven the
option to use something that was declared private (not public) and not mine
to use? seems to me this is somewhat malicious...
if not.... well....

Thanx,
Picho

Nov 16 '05 #2

P: n/a
Yes, this is intentional and it's necessary for a number of aspects of .NET
to function properly.

Remember, things like private and protected are generally language specific
issues, so you could very well write a language that didn't use access
modifiers and didn't respect them in the framework or other .NET software.
On the other hand, I wouldn't recommend using it willy-nilly.

There have actually been times where I've used it to bypass what I would
consider bad design choices by MS, to get at functionality in the underlying
framework that I otherwise couldn't. But I would not expect that code to
work in future versions of .NET, so consider doing stuff like that to be
non-portable and generally unsafe.

Pete

"Picho" <SP********@telhai.ac.il> wrote in message
news:Os****************@TK2MSFTNGP15.phx.gbl...
Hi all,

Using reflection, I can invoke/call private methods of an object.

is this intended?
if yes, why? in what scenario (example would be good) should I be givven the option to use something that was declared private (not public) and not mine to use? seems to me this is somewhat malicious...
if not.... well....

Thanx,
Picho

Nov 16 '05 #3

P: n/a
Pete Davis <pd******@NOSPAM.hotmail.com> wrote:
Yes, this is intentional and it's necessary for a number of aspects of .NET
to function properly.

Remember, things like private and protected are generally language specific
issues, so you could very well write a language that didn't use access
modifiers and didn't respect them in the framework or other .NET software.


I don't believe that's true - unless you are running in a full trust
environment.

While there are some access modifiers (I can't remember which off-hand,
unfortunately) which are more "advisory" than compulsory, I believe
most will be enforced by the CLR, at least when running in anything
other than full trust, and especially with verification on.

Note that without ReflectionPermission, you can't access non-public
methods via reflection either.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #4

P: n/a
I apologize, I should have been more clear. My meaning was, one could create
a language that ignored access modifiers by using reflection to call methods
that would otherwise be prohibited. You are correct, of course, that the CLR
will enforce access modifiers and that you'd need reflection permissions.

This has no been my day. My head has been in a cloud since I woke up. I
apologize for not being more clear.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Pete Davis <pd******@NOSPAM.hotmail.com> wrote:
Yes, this is intentional and it's necessary for a number of aspects of ..NET to function properly.

Remember, things like private and protected are generally language specific issues, so you could very well write a language that didn't use access
modifiers and didn't respect them in the framework or other .NET
software.
I don't believe that's true - unless you are running in a full trust
environment.

While there are some access modifiers (I can't remember which off-hand,
unfortunately) which are more "advisory" than compulsory, I believe
most will be enforced by the CLR, at least when running in anything
other than full trust, and especially with verification on.

Note that without ReflectionPermission, you can't access non-public
methods via reflection either.

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

Nov 16 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.