1 Replies - 17369 Views - Last Post: 14 June 2010 - 04:31 PM

#1 rgfirefly24   User is offline

  • D.I.C Lover
  • member icon

Reputation: 451
  • View blog
  • Posts: 2,190
  • Joined: 07-April 08

Compiled vs UnCompiled Website Code

Posted 14 June 2010 - 04:04 PM

So i got into a discussion with the person who does roll-outs at our office about how we are going to be deploying .NET code. He doesn't like using DLL's because he says its harder to manage the code, and would require that he is the one that compiles the code into the DLL. He thinks that even though the uncompiled code (which would have to go through the JIT) would be just as fast as the compiled DLL. What are your guys' thought on the Deploying of a web page. Are there instances where deploying uncompiled code to the web server is better then the DLL, or vise verse.

Personally I think that websites should be deployed as DLL's so that all supporting files can be included, with less of a likelihood of there being missed files. I also think that it will run faster as all the code is pre-compiled. I also think that with proper Source Control worrying about code management isn't as big of a deal.

Is This A Good Question/Topic? 0
  • +

Replies To: Compiled vs UnCompiled Website Code

#2 PsychoCoder   User is offline

  • Google.Sucks.Init(true);
  • member icon

Reputation: 1659
  • View blog
  • Posts: 19,853
  • Joined: 26-July 07

Re: Compiled vs UnCompiled Website Code

Posted 14 June 2010 - 04:31 PM

From this article


"When the first request arrives at your web application there is a mind-numbing amount of work to do. The worker process starts, the runtime initializes, ASPX pages are parsed and compiled to intermediate language, methods are just-in-time compiled to native code - and the list goes on and on. If you want to cut out some of the overhead and improve the startup time of your application, then you'll want to look at the precompile features in ASP.NET 2.0.

Although pre-compilation will give our site a performance boost, the difference in speed will only be noticeable during the first request to each folder. Perhaps a more important benefit is the new deployment option made available by the precompile - the option to deploy a site without copying any of the original source code to the server. This includes the code and markup in aspx, ascx, and master files."

For the record, in ASP.NET 2.0 when you Publish Website you're compiling the code behind files (asps.vb or aspx.cs) you're actually compiling them into a single DLL file so I almost think this is a mute point. I personally build sites straight on the server (I build a dev.sitename.com for the site) so I never click the Publish Website because the code is already there.

From here


n ASP.NET 2.0, you now have many, many options for deploying your applications, many of which overlap, none of which are simple, and none of which produce a repeatable install, except the uncompiled option which copies all files – source and all to and compiles everything on the fly.

The uncompiled compile is the simplest as it is an in-place mechanism that allows you to copy exactly what you have on your local machine to the server. But this install mechanism requires source code to be installed on the server, which is not the best of ideas for security and code protection.

One caveat to compiling your site into a single DLL is if a single page is altered then the entire site has to be redeployed


Microsoft apparently intended people to completely redeploy applications every time an update was made. The compilation creates a deployment folder with a copy of the Web site. VS 2005 includes tools that let you upload the deployment folder to your Web site. But that's pretty unrealistic. Typically you need to adjust web.config and possible other configuration files and you certainly wouldn't want to redeploy all of the incidental files like images for every update.

The bottom line is that, with this new mode, you can't update a site by simply copying one file. You can deploy compiled assemblies for each page, which creates one assembly per page which are stored in the BIN directory. That would be OK, except that every time you run ASPNET_COMPILER, the timestamp and file name changes, so the next time you upload you have to clean up the old compiled files. Options allow you to compile both ASPX and CS files or leave the ASPX file intact and let ASP.NET compile the ASPX page content at runtime.

Hope that gives you more information.

EDIT: For more information read The Server Side of ASP.NET Pages
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1