One option might be to mark all the exposed classes in your DLL as "internal" instead of "public", then use the "InternalsVisibleTo" attribute in your DLL to explicitly name the DLLs (and possibly exes) that are allowed to use your internal types. This may require all participants to be strongnamed, but that's a good thing to do anyway.
Ultimately, there is no absolute way to prevent a determined hacker from accessing your code when your code is executing on the hacker's machine. All code that can be executed by the machine can be disassembled and reassembled into something else with sufficiently advanced tools and experience.
The best way to approach code security is to ask the question "How difficult do we want to make it for someone to use this code without license or authorization, and how much time/money are we willing to spend to achieve that?" If you do nothing, it's 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 DLLs elsewhere. If you invest months of effort, you might be able to make it very difficult for someone to misuse your code, but you can never make it impossible.
One technique that is as close to absolutely secure as I can imagine is: don't execute your code on the client's (or hacker's) machine at all. Run a web service instead, and keep your code on the server where a hacker can't casually fire up a debugger on your process or disassemble your code. Your code security is then defined by the physical security at the server location and network access security to the server's ports. These attack vectors are many orders of magnitude more difficult to circumvent than anything you can do to code that executes on the hacker's machine.
For some software companies, moving a portion of their applications from the client to the cloud isn't about getting better scalability or easier updates or lower costs, it's about code security and piracy prevention.
