3

I come from a PHP/Rails background where deploying a website often means FTP/Checkout of the source code in the correct directory on the web server.

However, I've been asked to develop an ASP.NET website and some people have advised me to "Publish" the site instead of copying over the source code directly. Apparently, this converts the codebehind (.cs) files into compiled DLL's etc.

My application does not contain any specific secretive business logic. It's a common shopping cart app. My question is if this is a good idea? How does not making the C# code reside on the server make the app more secure?

Gaurav Gupta
  • 5,380
  • 2
  • 29
  • 36

4 Answers4

6

ASP.NET code will always be compiled - either:

  1. At run-time - you can copy .ASPX and .CS files to the server. When a page is requested the .ASPX and .CS files will be compiled on-the-fly. The ASP.NET run-time will create a DLL containing the compiled code (this lives in a folder called Temporary ASP.NET files and the location depends on the version of .NET you're using).
  2. Pre-compiled - you can choose to compile your code before deploying it to your server. This is what the Publish command does in Visual Studio. It compiles your .ASPX and .CS files into (one or more) DLLs that are then uploaded to the web server.

Personally, I don't think there's much of a security benefit from deploying pre-compiled code (unless you're obfuscating your pre-compiled DLLs).

That said I prefer it for these benefits:

  • It seems tidier, at least to me, than having a bunch of .CS files littered in a folder
  • There's a small performance benefit of not having to do C# compilation. Note your code will still need to be JITed from IL to native code and this still incurs the initial request performance hit (unless you use new ASP.NET 4.0 and IIS 7.5 features or something else).
  • The Publish feature lets you package your application up for deployment to other environments (testing, pre-production, production, etc.)

Note: coming from Rails/PHP you might like to keep on deploying both .ASPX and .CS files to your server. The benefit is that it's easier to modify a running application in a way you may be used to doing. This isn't a great practice if you're following a rigorous deployment lifecycle but it can be useful in some cases.

Community
  • 1
  • 1
dariom
  • 4,413
  • 28
  • 42
2

I can make one addition to the precompiling though, which has been mostly about security and performance; compiler checks!! Without precompiling you can easily upload some code file containing errors but not find out before 13 days later when the first user hits the page using this code-file. This is due to the fact that asp.net will only compile one file at a time whenever its needed.

With precompiling ALL the files will be compiled and ALL compiler errors be caught right away.

Thats all about precompiling though but publishing is not just about that.

Another important factor is the steps you can instruct msbuild to execute during publish. Maybe the most important thing is web.config transformation which you can read about here http://msdn.microsoft.com/en-us/library/dd465318.aspx. Basically you can create a transformation file that during publishing will replace/add/remove values from your web.config based on the publishing target.

Pauli Østerø
  • 6,878
  • 2
  • 31
  • 48
0

Yes, it's more about compiling than anything else. For the website to be able to run, the C# code must be compiled and that is what the publish step does, together with transferring it to a specific location.

The version of the website you have on your desktop is a development version, most likely with debug versions of the compiled code. With the publish step however, you should generate a release versions of the compiled code which also improves performance.

The publish step of ASP.net can be compared to creating an installer of a normal Windows application and, when published to an operational server, the install step combined.

Pieter van Ginkel
  • 29,160
  • 8
  • 71
  • 111
  • You can easily publish a debug version, release vs debug has nothing to do with publishing. You're right though about the installer-analogy since you with publishing can define steps that msbuild should do, make transformations to web.config, copy/create/delete files etc. during the publish phase, things you otherwise should do manually with pure xcopy deployment. – Pauli Østerø Nov 15 '10 at 15:06
0

Your c# code is still residing on the server, it's just residing as a compiled code instead in the form of a script as you are used to in PHP/Rails.

In PHP, rails or classic ASP, you write scripts and xcopy / ftp to your webserver. PHP interpreter then parses the script everytime a web request comes in vs. in asp.net the code is compiled and then copied to the webserver, so when a web request comes in, the execution is much faster.

Think of it broadly as deploying an .exe file on the server vs. writing the program in a text file and making a compiler parse the text file and running it every time.

It has nothing to do with being more secure or not.

Btw - How's life after Bluebells School :-)

ace
  • 2,141
  • 7
  • 29
  • 39
  • remember, that in .net the text file is only compiled once and the resulting dll is used until the text files changes, and not on every request. – Pauli Østerø Nov 15 '10 at 15:03
  • You seem to know me but I can't guess anything about who you are from your SO profile. Can you send me an email? – Gaurav Gupta Nov 17 '10 at 04:22