Hi,
I am trying to prevent reflection access to my dll.
the dll have one class name Class1:
public class Class1
{
    private int n;
    public int Value
    {
        get { return n; }
    }
}
I added an attribute to the AssemblyInfo.cs:
[assembly: ReflectionPermission(SecurityAction.RequestRefuse, Flags =
ReflectionPermissionFlag.AllFlags)]

but when I have a tester(other assembly an exe one) and trying to use
reflection on this dll no exception is  thrown:
public static void DoThat()
{
    Class1 p = new Class1();
    Console.WriteLine(p.Value);
    Type type = typeof(Class1);
    System.Reflection.FieldInfo field = type.GetField("n",
        System.Reflection.BindingFlags.Instance |
System.Reflection.BindingFlags.NonPublic);
    field.SetValue(p, 69);
    Console.WriteLine(p.Value);
}
am I missing something here?

I also tried to use ReflectionPermissionAttribute in the class level
and ReflectionPermission with Deny().
Something is wrong and I am sute that it is me.
Thanx

<shah***@gmail.com> wrote in message
Unfortunately, that's just not possible.


This will only block your assembly from being able to perform reflection
actions.  It will not block other code from accessing your assembly via
reflection.


Only that what you're trying to do simply isn't possible.  Do you have some
specific goal that you are attempting to accomplish via preventing
reflection into your code?  If so and you could explain what it is, it might
be possible for someone here to suggest an alternate approach.


Unfortunately, denials are just as useless as RequestRefuse wrt attempting
to prevent reflection into your assembly.

I want to prevent other code that is use my dll to invoke private
members.
Show quoteHide quote

Hello,

in a full-trust environment, its not possible.

Greetings,
Henning Krause

<shah***@gmail.com> wrote in message
Show quoteHide quote

You cannot prevent fully trusted code from invoking your private members.
If you want to be absolutely sure that your private members cannot be
called, you'll need to keep your assembly off any machine where it may be
subject to execution by potentially malicious (at least from your point of
view) highly privileged code.  That said, there are some scenarios in which
one can reduce the potential problems caused by invocation of private
members.  For example, if one suspects that private fields may be
manipulated in unexpected ways, one might wish to revalidate them before
using them as opposed to only validating them via their setters.  In
addition, you may wish to protect some of your private methods with license
or other "right to call" verifications in a manner similar to what you might
do for public methods.  Obviously, approaches like these will have
performance consequences, and they can be bypassed by a sufficiently
determined and highly privileged attacker, so ymmv...



<shah***@gmail.com> wrote in message
Show quoteHide quote

System.Security.SecurityException was unhandled
Problem with RSA.ImportParameters() under ASP .NET
after changed the permisssion set to "nothing", I can't set the .net configuration anymore?
moving .net containers
CryptoAPI
Encyption
NEED Solution for .NET 2.0 mscorcfg.msc w/o SDK
impersonation in vb.net
web.config security conn-str and auth-info
Blocking hyperlink access to 'secured' website