Coding Horror: Code-Behind vs. Inline Code

January 4, 2005

Code-Behind vs. Inline Code

After religiously adhering to the new, improved code-behind model of ASP.NET for so long, I have to admit it's sort of refreshing to rediscover inline code ASPX pages again. Deploying single web pages to a server without recompiling the entire solution? Making localized edits to single pages that take effect in real time? A single file that contains both code and markup in one convenient self-contained package? Revolutionary!

I've worked with code-behind for so long I actually didn't even know how to convert a page to the code inline model. As expected, it's quite simple:

Open the HTML (.aspx) view of an existing ASPX code-behind page.
Add or modify the following page directive:
```
<%@ Page Language="vb" Strict="True" %>
```
Paste all the code from your existing code-behind (.vb) into a HTML script block:
```
   <HEAD>
     <SCRIPT language="vb" runat="server">
      (page class code goes here)
     </SCRIPT>
   </HEAD>
```
only paste the code inside the page class, under the "Web Form Designer Generated Code" region. Don't paste the class itself!

Don't forget to add any imports your code needs; these can go just above the page directive.

   <%@ Import Namespace="System.IO" %>
   <%@ Import Namespace="System.Text" %>
   <%@ Import Namespace="System.Text.RegularExpressions" %>
   <%@ Import Namespace="System.Configuration" %>

Delete the associated .vb code-behind file.

That's it! You now have a single file webpage that dynamically compiles. Copy that single file to a target website and, assuming it doesn't have any other dependencies, it'll load right up.

Unfortunately, Inline ASPX pages also remind me of some things I didn't miss from the bad old days of ASP programming: spaghetti code, extremely limited intellisense, and crappy debugging. On the whole, I'll stick with code-behind, but I might vacation in Inlineville from time to time.

Inline code pages clearly have their place; I use them mostly for utilities where ease of deployment into existing websites is the overriding concern. However, I do think you can also make a fairly compelling argument that the current ASP.NET code-behind model is a bit too restrictive; you end up with a humongous web.dll that has to be recompiled even if the tiniest bit of code in the most trivial web page in your solution changes. It'll be interesting to see what kind of improved, hybrid behind/inline model we get in VS.NET 2005.

Posted by Jeff Atwood View blog reactions

« On mistakes

If an Exception happens in Form.Paint, does anyone catch it? »

Comments

The Whidbey model will be improved in a couple of ways. One, the IDE has full support for inline code, which includes IntelliSense not just for code, but for HTML, ASP.NET tags, client script, page directives, you name it. So there will be no reason not to use inline code if that's your preference.

The code-behind model is likewise improved. A code-behind file will be a "partial class" file that contains only your user code; all the gen'd code junk that VS needs to create a full class will be inferred and generated at compile time. Code-behind is also now dynamically compiled by default rather than compiled into a big ol' assembly at design time. You can deploy an .aspx file and a .vb file, and they will be compiled at runtime, just like single-file pages. (Alternatively, you can pre-compile your site and deploy just the object if you want.) As another improvement, you can now create an App_Code folder and put source code into it; it acts like the Bin folder, only it works with source. In the IDE, this App_Code folder is _also_ dynamically compiled, so you can get IntelliSense against it as well.

And more improvements as well. One more: no more dependency on project files. Although project files exist, dynamic compilation is not driven off them; whether you use VS or not, the runtime is driven off what's actually in the folders, not off references in the project file. Deployement, with or without the IDE, can be as simple as copying directories.

Anyway: Whidbey rocks. It sounds a little dumb to say that, but so much has been fixed along these lines that it will truly be a different (and better, duh) experience. IMO, of course. :-)

mike on January 5, 2005 10:34 AM

Yep, that's what I thought; thanks for the specifics. 2.0 is going to be a major improvement as expected!

Jeff Atwood on January 5, 2005 2:05 PM

Yes, I'm looking forward to 2.0 and being a bit more 'liberated' with some projects. I've been suprised how many people have taken to code behind as it is such a polar oppisite of what an ASP dev is used to, but I guess that is what a good IDE can do. Still, flexibility is nice.

Scott Allen on January 6, 2005 2:14 PM

One caveat: the "Handles" method of wiring events doesn't work for inline code. Instead you modify the OnClick attribute of the server-side ASP:BUTTON (or whatever element):

<ASP:BUTTON id="AddWorkspaceButton" runat="server" text="Add New Workspace" onclick="AddWorkspaceButton_Click"></ASP:BUTTON>

Jeff Atwood on April 5, 2005 2:57 PM

I didn't even know you could do inline code for ASP.NET until a couple of weeks ago. I did find a fairly nice editor for doing this type of coding however. Microsoft's ASP.NET Web Matrix. Not only will it do inline coding, it also will do WYSIWYG form designing and has property panels just like VS.NET. It also is very helpful as you can view the code and HTML seperately(there's a logical, not physical seperation made).

The one huge drawback to it is that it has no intellisense, but it is free.

http://www.asp.net/Default.aspx?tabindex=0&tabid=1

Marty Thompson on April 6, 2005 9:15 AM

Even when using code-behind you can still have your code dynamically compile from the .cs file by including a reference to it in the Src attribute of the Page directive. The Src attribute does a similar job to CodeBehind, except that is only used by vs.

eg.
<%@Page ... Src="mypage.cs" ... %>

You can add the Src attribute to pages that were originally pre-compiled in vs but you'll need to take it out again if you want to go back to pre-compiling your project.

<a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconpage.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconpage.asp</a>

<a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconwebformscodemodel.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconwebformscodemodel.asp</a>

Raith on November 28, 2005 4:57 AM

its interesting .. but i prefer code bebhind coding.. can any 1 plz tell me the cases where inline coding is preferred..

sneha on September 30, 2006 12:20 AM

Actually I started hacking inline files with notepad and learned about the IDE and code behind later. A single file, partitioned between markup and script is much more elegant. There really is little to be gained by precompiling this stuff. Ease of use and simplicity is more important.

Chris on January 2, 2007 6:08 PM

Hi,
I was wondering if it is possible to to inline and code behind at the same time on a page??

john on August 31, 2007 6:39 AM

Hello!!! Have a good day and God Bless you!!!
I just think it�s a manner to keep the bussiness. We've gotta develop with Microsoft Visual Studio .Net 2008

aebordones on May 7, 2009 2:41 PM