It might put you at ease to know that you don't actually publish your .cs/.vb files with the website when you publish as a dll. I think this is the easiest road block to put in place.

I realize that you can still get code out of the DLLs but the source files themselves don't need to be there.

Convert your web project into a Web Application and build it. The output will be a dll. Push this along with all the media files (aspx, gif, png, etc.) out and your source should be hidden from less-than-diligent people.

From stackoverflow

• Read here and here for instructions on how to deploy as a binary

  Read here for a good Obfuscator

  I don't know what you mean about "3d party" but the above links will help you protect the code.

• You are going down the right track. THe DLL is a big help, but it can be de-compilied to at least get some.

  Using an Obfuscator like Dotfuscator is a good extra step. This FAQ is a good starting point to understanding Obfuscators

  The key is to identify what you are looking at doing. If you are deploying the code, it is going to be farily hard to stop someone from calling methods inside the code. If you are just looking to prevent them from getting the actual source, that is easier and obfuscation should work.

• I would always choose to pre compile the website into a DLL and not include the code online. This means that anonymous users will not have access to your code.

  However if you are concerned about people with admin access to the server it would be possible for them to disassemble your binaries into something almost readable.

• There is a way to precompile all aspx/ascx files in an ASP.NET web site or project using a Visual Studio project template:

  Read here on ScottGu's blog: VS 2008 Web Deployment Project Support Released

  Compiling the deployment project a single assembly is created for all your aspx/ascx files.

  If you want to really hide (make unreadable) your source code, you should use a professional obfuscator software.

• Maybe I'm wrong, but I'm not convinced that IIS will serve any files from the bin folder (it doesn't for me anyway, and I assume this is by design in the same way that you cannot donwload web.config - it also won't even list the directory contents). If this is correct, then I'm not convinced there's a way for a hacker to obtain the dll in the first place, unless they can get filesystem access to the server.

  If you follow the advice given above about compiling into a single dll, I don't think you need an obfuscator (unless you're concerned about people WITH filesystem access, in which case I think you have other problems!)

• In my experience people who are obfuscating their code don’t produce code that is worth the trouble.

• Which version of VS are you using? In VS2005 SP1 there is a new project type called Web Deployment. Right click on the website name in the solution explorer, and you should see an option "Add Web Deployment Project" - this adds a new project to your solution that will create a single DLL and alter the aspx pages to reference it.

  When you build the solitution, it creates in the web deployment project folder a version of the site with the single dll. Copy this to the server, set up your db and any file system permissions (e.g. for uploads etc.) and you're away.

• When you publish your project as binary, the compiler will create DLL(s) in the bin folder and all pages you have are also created, but not with code in, just one line that says its a marker file. So when the user browse your site they will browse the pages as usual. Your pages will then on the serverside point to the right code in the dll

• After you publish as a DLL, don't forget to put it (and the other server-side files like Web.config) in a path that isn't served by IIS.

• 1. I know also that ASP.NET when published can be precompiled
  2. I know that .NET applications are compiled to MSIL that are easily reverted to any .NET language through tools like Red Gate's .NET Reflector.
  3. I want to develop and deliver an ASP.NET site where the buyer will host the site and but cannot have access to the code.

  There is any way to do that?

  Matt Briggs : This is officially the first time I have seen it referred to as Red Gate's Reflector as opposed to Lutz Roeders Reflector. Sort of sad in a way

  Jader Dias : Is how it appears on my screen

• You can look into obfuscation. Dotfuscator is a good place to start.

• It's called "obfuscation". There are commercial products which do that. It will not exactly prevent decompiling, but it will mess up the insides of your program so much, that it will be difficult to make heads or tails of it.

  Note that it may also break your code under special circumstances, so you will have to play with its options until you get it to work.

  Dotfuscator is a popular one, and a stripped-down free community version comes with Visual Studio (not sure which editions though).

• Tell them not to. You'll never stop a determined reverse engineer, but if it's in the contract, you'll have recourse against someone profiting from it.

  Obfuscation makes debugging much harder, not only for you, but also for your customers if they're plugging into your code.

  Another reason to avoid it is the temptation to slip towards including "secret" ports, encryption keys or handshakes. You will need to find a very different model if you have any of these in your code.

  DrJokepu : Apparently I'm not the only one in the anti-obfuscation camp! That's a relief.

  backslash17 : This is an Utopia!

  Mark : Thinking that you're better than reverse engineers is Utopian. Check out http://docs.google.com/viewer?url=http://www.offensivecomputing.net/bhusa2009/oc-reversing-by-crayon-bhusa2009.pdf

• Just an idea but it may not be your case:

  Use web services in some point of your app if it is possible. Distributed code makes that only the client logic is available to decompilation.