mkaring / ConfuserEx

An open-source, free protector for .NET applications
https://mkaring.github.io/ConfuserEx/
MIT License
2.39k stars 370 forks source link

Merging or scattering static classes #164

Open wmjordan opened 4 years ago

wmjordan commented 4 years ago

For assemblies with many helper methods, this can lead to a very large class.

Could this add difficulty to analyzing the structure and purpose of the classes before merging?

Before:

static class A {
  public static void M (){}
}
static class B {
  public static void M (){}
}

After (using debug renaming):

static class _A_B {
  public static void _A_M (){}
  public static void _B_M (){}
}

Candidates for merging should meet the following principles:

  1. static class.
  2. same accessibility after possible internalization.
  3. no generic type parameter in the class level.
  4. no attributes applied to the class (except some which do not bring side effects, such as ExtensionAttribute, CompilerGeneratedAttribute etc. maybe this can be configurable via crproj files).
  5. do not call each other when initializing static fields (to avoid unexpected initialization).

Variation of this pattern may be:

  1. scattering the static class into multiple classes.
  2. interlace scattered classes with others (into unrelated classes, including instance ones).
  3. nesting scattered classes.
mkaring commented 4 years ago

From the top of my head I think the main challenge here is to ensure that this does not break the access by reflection.

wmjordan commented 4 years ago

Yes, reflection is the problem. My projects will break immediately after that :D.

However, if a user knows the above rules, it is pretty easy for him to exclude a static class from this kind of protection: add an attribute to it. For experienced users, they can exclude or include classes via metadata or crproj file.