How to secure .NET DLL's

What is best practice for securing DLL's for 开发者_开发百科projects you are working on? Certain DLL's I am interested in developing will have data access layer (DAL) and business logic layer (BLL) functionality. There may be several apps that can eventually hit these DLL's to perform business specific functions.

What is the best way to secure these DLL's so they can only be used by only creator's applications?

Security for both blocking unauthorized use of the DLL's and security against possible decompilation are both desirable.

---

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.

---

Establish authentication using Open Key mechanism. The functions in the DLL will only work if you supply a valid key and the token.

---

If someone has access to the machine with all those assemblies, you have more to be worried about than someone reusing them, they could just go directly to the database instead of using your assembly.

If this is a desktop application or something and you're accessing the database directly then you need to re-think your application, access the data via web services or something rather than going directly to the database.

---

Protecting your intellectual property is not really possible if you ship it in the form .NET DLL's to a client. You could host your application logic in the cloud, though that might not suit your scenario.

Even the "best" obfuscators aren't infallible. You could probably put off a casual hacker, but as dthorpe says, if someone really wants to decompile your assemblies, they will.