0

I've written some code in C#, and I would like to distribute it as a DLL. I know there are a lot of resources for this, but I'm having a strange problem, and I'm new to C# and thus lack the vocabulary to properly search for solutions.

The situation is : I have my code in a Visual Studio project, and it works great. I can compile it, and I see the mycode.dll file in the bin. I believe that this (along with any other required DLLs) is what I need to pass on to other users. To check this, and to make sure things are working as I want them to, I created a second Visual Studio project to use the DLL I'd created.

For the most part everything looks good. The problem arises when I get a runtime error in the DLL code. When that happens, I get a dialog box describing the error, with "Break" and "Continue" options. If I choose "Continue" it takes me to the place in the source code where the error occurred. I don't want the user to be able to see my source code like this.

I've tried signing the project (in the Properties menu), but that doesn't seem to solve the problems, and also leads to compile time errors because some of the other DLLs I'm using aren't signed (at least, I think that's what the error means).

Is there a way to compile my code in to a DLL that will not allow the user to see any of the source code?

Thank you

stranger
  • 390
  • 4
  • 17
  • Visual Studio shows you the code because it has that code available in the form of the `cs` files. End users don't have them. But they [can have them](http://stackoverflow.com/q/9025186/11683) if they want. You can only make their life [slightly harder](http://stackoverflow.com/q/2525/11683). – GSerg Feb 13 '15 at 22:17

4 Answers4

4

Signing (Strong naming) a DLL have nothing to to with Obfuscation. When you deliver a dot.net assembly, everybody can decompile it. If you obfuscate it, it's harder to decompile, but not impossible.

Signing is only a way to guaranty others projects using your DLL, that another DLL doesn't replace the original one.

You can check yourself if you can decompile your assembly with reflector.

PS : if a project using a signed DLL is not signed itself, it should not throw compile errors. It's the inverse which throw exceptions : when you use not signed assemblies in a signed project.

rducom
  • 7,072
  • 1
  • 25
  • 39
  • Thank you very much. WRG to your P.S., that is the situation: I have unsigned assemblies, and when I tried to sign my project I got errors. Sorry for the confusion. – stranger Feb 13 '15 at 22:38
  • Note that as today Obfuscation has never been a guaranty for code protection. But I think things will soon change with crypto code protection, since today I read this : http://www.wired.com/2015/02/crypto-trick-makes-software-nearly-impossible-reverse-engineer/ – rducom Feb 13 '15 at 22:46
3

Here Visual Studio is trying to help you, the programmer, debug your code. Be assured that if you ship just the DLL, your source code doesn't ship along with it. Visual Studio was able to find it because it knows where your source code is.

That said, the DLL you ship is easily decompiled to something very near the original source using a tool like JetBrains dotPeek. It takes more effort than being thrown into the source code by Visual Studio, but it's not hard.

adv12
  • 8,443
  • 2
  • 24
  • 48
3

As mentioned, this is a case of Visual Studio trying to help. To ensure you're not shipping the data that causes this, do the following

  • Make sure you only ever ship builds using the Release configuration. This does nothing in and of itself, but does offer you an easy way to segregate behaviour from your-usage to outer-usage
  • Make sure that the release configuration doesn't generate a PDB (project properties -> build -> advanced -> output, Debug info). This is the file that allows Visual Studio (or Xamarin, or Sharpdevelop...) to associate running code with the corresponding piece of source code - not having this file limits end users to decompilation.
  • Obfuscation: technically a large leap, this will make decompilation of your code (via ILSpy or DotPeek) much more difficult, and the resulting code much more difficult to understand. There are many tools for this, but it refers to making the compiled code scramble member and type names (if you've ever opened the JAR of Minecraft, you get an idea of what this does)
    • Be warned, this step can break certain code if you (or something you rely on) uses a lot of reflection and thus needs member names to be correct - See ObfuscationAttribute for one way to curb this issue
David
  • 10,458
  • 1
  • 28
  • 40
0

In .NET core the problem is solved, You can combine all the dll to one exe. This way the user will not have access to dll file.

Next they can de-compile exe, for this you can put some sort of security check or licence system (offline or online) to secure your exe.

And if you are making web application you do not have to worry about this problem.

Nishant Kumar Verma
  • 424
  • 7
  • 18