Groups | Blog | Home
all groups > c# > august 2004 >

c# : Hide Interface?


Ignacio Machin ( .NET/ C# MVP )
8/26/2004 3:49:20 PM
Hi,

Do not make it public.

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation


[quoted text, click to view]

Nicholas Paldino [.NET/C# MVP]
8/26/2004 4:04:18 PM
pnp,

Even if you were able to hide it from an object browser, the metadata
for the interface could still be read (if you have to make it public, then
there is nothing you can do about this).

However, if you are dealing with object browsers that use the Reflection
API, then you can probably place a ReflectionPermission attribute on your
types, denying the permission. This should offer some sort of protection.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com

[quoted text, click to view]

pnp
8/26/2004 10:22:10 PM
Is there an attribute (or another method) to hide an interface (in a dll)
from being seen from the object browser while browsing a dll?

Thanks in advance,
pnp

pnp
8/26/2004 10:55:03 PM
The problem is that it has to be public because it is being used by other
assemblies... The need to hide it is for security reasons.

Can anything be done?



[quoted text, click to view]

pnp
8/26/2004 11:08:32 PM
I'll give it a try, thank you both.


"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:%23JGr6f6iEHA.2500@TK2MSFTNGP15.phx.gbl...
[quoted text, click to view]

pnp
8/27/2004 9:14:44 AM
Could you post me an example because I didn't have any luck by trying it my
self?


"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:%23JGr6f6iEHA.2500@TK2MSFTNGP15.phx.gbl...
[quoted text, click to view]

Nicole Calinoiu
8/27/2004 6:34:50 PM
Nicholas,

Do you have any evidence that denying ReflectionPermission (or any flag
subset) via an attribute at the class or member level has any effect at all?
I've tested quite a few variations on the theme (incl. imperative denial of
the permission), and I've never seen any effect on member discoverability or
accessibility via reflection.

It could be that the reflection methods are asserting the permission after
an initial stack walk to determine if the desired activity is permitted to
the callers. This would make sense in an odd sort of way since the
ReflectionPermission settings for the target can't be determined until after
it's already been loaded. That said, it would still be terribly
inconsistent with the expected behaviour for a CAS permission...

Nicole



"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:%23JGr6f6iEHA.2500@TK2MSFTNGP15.phx.gbl...
[quoted text, click to view]


Nicole Calinoiu
8/28/2004 10:54:38 AM
Actually, ignore the second paragraph of my last post entirely. The
framework almost certainly doesn't need an assertion to prevent the deny
from working since there's no need for ReflectionPermission to be evaluated
after the target is loaded. In fact, to be consistent with the other
permissions, stack walk modifiers on the target class or member should
probably be ignored. For example, a file doesn't get to specify a modifier
for a FileIOPermission (ignoring the fact that there's no mechanism in place
for this <g>), so why should code get to specify a modifier for
ReflectionPermission? Doesn't mean I necessarily like the behaviour, but
there is a certain logic to it.



"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:%23JGr6f6iEHA.2500@TK2MSFTNGP15.phx.gbl...
[quoted text, click to view]

AddThis Social Bookmark Button