How can I protect my Assembly to being used by someother?

how can I protect my assembly, because once I deploy the setup, assembly will be deployed too, and there are chances that user will get the 开发者_开发知识库assembly from Program Files, and may add reference to any other project or create new project based on it ! any solution or help would be appreciated thanks.

---

You can make all members inside the assembly internal, and only allow others to use it by the InternalsVisibleToAttribute. But if someone is persistent enough, there is no way to stop them from using it.

---

You could obfuscate the code of your assembly which will render the task of using it more difficult but there's not much you can do to 100% prevent a user from picking the assembly and using. What you could do is NOT to deploy the assembly on the user computer but provide the functionality through a web service.

---

You can't totally prevent that. But you could obfuscate your assembly in a way such that the classes and methods exposed don't have any reasonable names.

One such obfuscator is opensource and called obfuscar. A continued project can be found here under this link.

---

There is no simple way. You can only make it more difficult. If your algorithms are so unique and precious[1] that you need to make them impossible for third parties to use (or peek in), your only choice is to have the logic in a remote place (behind a server) and have your program call it.

[1] Something that, in my humble experience, is never the case.

---

You could use ILmerge to merge the assembly into the executable, and then use obfuscation to protect the whole package (.NET executables can be treated as assemblies you can link to).

---

While it obviously isn't secure - you still have to store the decryption key somewhere - it works perfectly fine to encrypt your DLLs on disk, then load them and decrypt in memory.

If you hook AppDomain.CurrentDomain.AssemblyResolve with a custom handler, you can even do it transparently - when your assembly tries to load a specific DLL, it fails, your handler fires, and loads the assembly from the encrypted DLL.

I've yet to find any problems with this approach.

Also, if you're only worried about people using your finished DLLs in their own projects, you could add a few stack checks to your code, as well as resolving which assembly is running and performing a hash check on it. Both of these countermeasures can easily be edited out of your DLL, however.