Some precautions for. Net code obfuscation

Since. net is always able to be cracked, so we have to put important computing and functions on the server and provide them through webservice, but the client code is always confused, otherwise, the obfuscation function of code protect tools is used instead of encryption. After all, encryption can be cracked.

Take XENOCODE as an example (in fact, I only use this, after all, I believe in the old software, and I have a bottom point). Its select pattern is quite good. After a period of exploration, find some notes:

1. Do not rename Enumeration: after all, we still use Enum. Parse (string) and tostring to get the name.
2. It is recommended that you do not rename the Reference and Interface.
3. public and protect cannot be renamed: because public will be used externally, and some will be virtual override or implicitly implement, while protect will be used by other inheritance classes.
4. It is best to separate an assembly for reflection, so don't confuse it: after all, this risk is too high, and it is difficult to choose one by one and choose which and not rename, for example, some ORM needs to reflect the object class definitions of attributes and fields.
5. Change the resource class Properties. Resources to public (in this way, public can be set in batches and not renamed)
Because this code
Global: System. Resources. ResourceManager temp = new global: System. Resources. ResourceManager ("XXX. Properties. Resources", typeof (Resources). Assembly );
ResourceMan = temp;
Otherwise:
Cocould not find any resources appropriate for the specified culture or the neutral culture.

Others:
There is no error in string encryption, but there is some performance loss.
Process obfuscation xenocode is still safe. I generally use 1 ~ Level 2 is enough. After all, sometimes I have to open the obfuscated code to find the location.
I have not set other options to prevent decompilation, because I have to use reflector myself.