views:

175

answers:

6

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.

+2  A: 

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.

Darin Dimitrov
+2  A: 

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.

Sebastian P.R. Gingter
+4  A: 

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.

Yuriy Faktorovich
+1  A: 

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.

Yann Schwartz
A: 

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).

Cecil Has a Name
A: 

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.

cctsm