One option would be to mark all public classes in your DLL as “internal” rather than “public”, and then use the InternalsVisibleTo attribute in your DLL to explicitly specify the DLL (and possibly exes) that are allowed to use your internal types.This may require all members to get a nickname, but that’s good anyway.
Ultimately, there is no absolute way to prevent your hacker from accessing your code when your code runs on a hacker machine. All code that can be executed by the machine can be parsed and compiled into something else with fairly advanced tools and experience.
The best way to ensure code security is to ask the question: "How difficult is it for someone to use this code without a license or authorization, and how much time / money are we willing to spend to achieve this?" If you are not doing anything, it is very easy for someone to use your DLLs in some other project. If you do a few simple things, you can make it inconvenient for someone to use your DLL files elsewhere. If you spend months of effort, you can make it very difficult for someone to misuse your code, but you can never make it impossible.
One method that is as safe as I can imagine: do not execute your code on a client (or hacker) machine at all. Instead, start the web service and save your code on a server where the hacker cannot accidentally launch the debugger into your process or parse your code. Then, the security of your code is determined by physical security at the server location and security of network access to the server ports. These attack vectors are much more difficult to circumvent than anything you can do for code that runs on a hacker machine.
For some software companies, moving some of their applications from the client to the cloud is not about improving scalability or simpler upgrades or lowering costs, but also protecting the code and preventing piracy.
dthorpe
source share