Re: Accessing SetStyle from Outside the Control

Question

Wait a minute - I don't believe what I am reading.  Using reflection, we can bypass the protected and private members of an object?  For example, uisng reflection, I can mofiy the value of a private field in an instantiated object, a private field, that may represent the internal value of a public property, bypassing any limitations or control coded into the property's accessors?

Doesn't this defeat the aspects of the object oriented approach, you know, like encapsulation, for example?

Answer 1

The topic of reflection and it bypassing set limitations or OOD is better suited for the CLR forum (http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=44&SiteID=1) or the .NET Development General form (http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=39&SiteID=1)

 

-mark

Program Manager

Microsoft

This post is provided "as-is"

 

 

Answer 2

But the answer to your question, Matty, is yes, if the executing code has the proper permissions.

Answer 3

Was that an admittance of Reflection defeating the purpose behind Object Oriented Design? It is a bit scary that not only can someone get a full listing of all private and proteted fields and functions but that they can change them and use them at will.

Answer 4

Hello Matty,

As noted in another response, some Reflection permission flags allow code to access private and protected members.

In a sense, this violates the object oriented object model of the targetted assembly. However, this permission was not created for those scenarios. It was created to allow developers to create hosts and tools [even algorithms] which can access the object model for OM analysis [such as FXCop, Permission Calculator, documentation, etc.].

Similarly, this permission is only granted to highly trusted code - not code loaded from the Internet, for example. Beyond being a violation of OM semantics, it could also very likely be a security issue since the Reflecting code could bypass security gate APIs.

 

Hope that helps,
Stephen [Microsoft CLR: Security - Developer]
http://blogs.msdn.com/stfisher