Signing .NET assemblies: Does this protect my assembly from tampering really?

I am implementing a "locking" system in my app which protects my app against being copied and used illegally. The system checks the signature of a hardware-based code and expects it to be signed with a Private Key that only my company owns. (The app has got the Public Key to validate the signature.)

I want to make sure that no one changes my locking mechanism in the app, so I want to sign my app's assembly and I think it makes sense.

1. Since I haven't seen the CLR ever talk about an assembly's signature being invalid, I want to make sure this system really works. Does it? What should I do to make it work?
2. Can an attacker concentrate his efforts on the CLR to make it not care about my signature? That is, if he can't tamper with my code because I've signed it, can he tamper with CLR?
3. Generally, I would like to know your experience about such safe-guards and protection technologies. Can any one suggest anything else?

Assembly signing is designed to allow applications/assemblies to reference an assembly and be sure that they get the assembly they originally referenced. If someone wanted to, they could in theory decompile your entire app and recompile with no signing. (ie: they could recompile the referencing assembly so that it referenced an unsigned version of the referenced assembly).

They would then be able to modify the code as they wanted, because the client (exe) would now reference an unsigned (or 're-signed') dll.

To make the process of decompilation and recompilation more difficult, you could try creating a mixed-mode C++/CLI assembly containing both managed and native code. But yeah... ultimately people have all your binaries to hand and with enough effort can probably get round any licensing system you think up.