SkipMethod "protected" tag bug for "protected internal" methods.

[GoogleCodeExporter]

Hello,

I found bug when we using SkipMethod tag.

add this to .xml configuration file:
<SkipMethod type="*" attrib="protected" rx=".*" />

make method:
protected internal void Test()
{
}

This method will be renamed because have "internal" and "protected" flag
simultaneously.

How to fix:
open MethodTester.cs
in the CheckMethodVisibility() method
replace:

if (accessmask == MethodAttributes.Public || accessmask ==
MethodAttributes.Family)

to:

if (accessmask == MethodAttributes.Public || accessmask ==
MethodAttributes.Family || accessmask == MethodAttributes.FamORAssem)

Original issue reported on code.google.com by IvanEfi...@gmail.com on 8 Feb 2010 at 1:14

[GoogleCodeExporter]

Hello Ivan,

actually this behavior is intended.
Internal methods cannot be accessed from outside of the assembly. They look like
private members to other assemblies.
Therefore - in my opinion - it does not make sense to exclude them from 
obfuscation.

Please tell me, why you would want to treat "internal" members in another way 
than
"private" ones when it comes to obfuscation.

Werner

Original comment by webbi...@gmail.com on 8 Feb 2010 at 8:20

[GoogleCodeExporter]

Hello,

Here you can see "protected" and "internal" method.

I mean this:
protected internal void Test()
{
}

this method can be used as "internal" and as "protected".
Such methods must be excluded from obfuscation if we have "<SkipMethod type="*"
attrib="protected" rx=".*" />", because this is "protected" too.

Original comment by IvanEfi...@gmail.com on 8 Feb 2010 at 11:54

[GoogleCodeExporter]

The attrib="protected" and attrib="public" attributes on skip-elements are 
primarily
intended for exposing the public and/or protected members of an assembly to 
external
callers. In a usable, hence unobfuscated way.
But why would anyone want to skip "protected internal" members from 
obfuscation, when
they cannot be used by external code anyway. This makes no sense to me.

I won't change the current behavior until someone gives me a good *practical* 
reason
why it is indicated.

BTW: That "internal protected" may also be called "protected" is true. But 
there is
no "external" keyword in the C# language, so "protected" and "internal 
protected" are
two distinct things in this context. And "internal protected" is the less 
accessible
of both.

Original comment by webbi...@gmail.com on 8 Feb 2010 at 3:45

[GoogleCodeExporter]

> But why would anyone want to skip "protected internal" members from 
obfuscation,
when they cannot be used by external code anyway. This makes no sense to me.

Sorry for my bad English.

See next example please.

--------

one assembly:

public class BaseClass
{
   protected internal void Test()
   {
   }
}

class SomeClass
{
  void Method()
  {
    BaseClass obj == ...;
    //Use "internal".
    obj.Test();
  }
}

-----------

second assembly:

public DerivedClass : BaseClass
{
  void Method()
  {
    //Use "protected".
    Test();
  }
}

We using this in the our commercial products. Of course we can make 2 methods
(protected void Test(), internal void Test2() ), but this is base C# feature 
and we
use it.

Original comment by IvanEfi...@gmail.com on 8 Feb 2010 at 4:15

[GoogleCodeExporter]

Having examined the language spec, it looks like "protected internal" allows 
you the
sum of both permissions, not the intersection, so this may actually be 
considered a
bug. (IE, the "protected internal" function is more accessible than just 
protected or
just internal.)

Based on the amount of confusion generated by this bug report, I will not be 
using
this language feature in my own projects. :)  But, Ivan appears to be correct, 
and
this is definitely something to fix.

Original comment by tekh...@gmail.com on 8 Feb 2010 at 7:19

[GoogleCodeExporter]

Sorry, Ivan. I should have checked the language specs like tekheed (thx!) did.

I will fix that and publish a new version of Obfuscar right until tomorrow.

Werner

Original comment by webbi...@gmail.com on 9 Feb 2010 at 8:55

• Changed state: Started

[GoogleCodeExporter]

:)

obfuscar - very good tool.
Thank you!

Original comment by IvanEfi...@gmail.com on 9 Feb 2010 at 9:22

[GoogleCodeExporter]

Original comment by webbi...@gmail.com on 9 Feb 2010 at 6:42

• Changed state: Fixed