Asp.Net inline (single-file) vs code-behind

asp.net

In the transition from classic ASP to Asp.Net some developers took to putting their server side code in a block at the top of their HTML ala:

<%@ Import Namespace="MyDll" %>

<script runat="server">
    void Page_Load()
    {
    }
</script>

This single-page model has some advantages as Jeff Atwood describes, however, in my experience I have seen nearly all code put in a separate code-behind file in recent times (ie with VS 2008).

Nevertheless, it turns out a colleague strongly prefers the single file (inline) method over the separate code-behind method.

What are the strengths and weaknesses of each approach? (I've noticed that code collapsing and #regions don't seem to be supported. Also the pages get rather long and there is no longer the visual separation of client and server side code. Can you tell I have a preference?)

I realize that variations of this question have been asked before, but I haven't seen anyone actually spell out specifically the pros and cons of each method.

EDIT

Thank you everyone for your thought provoking answers. I'm still hoping for a list of strengths and weaknesses of each method. What are the actual features that each has (or doesn't have)?

Best Answer

There's no doubt in my mind that the code-behind or mvc models are superior for almost everything you want to do. However, even today I still find myself using inline code for most of my pages. Why? Because there's one big scenario where the inline scripts really shine.

If you have a large amount of legacy ASP Classic code that you don't want to just throw out, including a deep nesting structure, it all lives in one big application, and you want to share that application with your asp.net code, you can just drop inline asp.net pages right in your existing web file system and they'll just work.

This sounds like exactly where your other developer is coming from.

Website:

The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing.

If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name, which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be popular.

Web Application:

The Web Application Project was created as an add-in and now exists as part of SP 1 for Visual Studio 2005. The main differences are the Web Application Project was designed to work similarly to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build time. To update the project, it must be recompiled and the DLL file published for changes to occur.

Another nice feature of the Web Application project is it's much easier to exclude files from the project view. In the Web Site project, each file that you exclude is renamed with an excluded keyword in the filename. In the Web Application Project, the project just keeps track of which files to include/exclude from the project view without renaming them, making things much tidier.

Reference

The article ASP.NET 2.0 - Web Site vs Web Application project also gives reasons on why to use one and not the other. Here is an excerpt of it:

You need to migrate large Visual Studio .NET 2003 applications to VS 2005? use the Web Application project.

You want to open and edit any directory as a Web project without creating a project file? use Web Site project.

You need to add pre-build and post-build steps during compilation? use Web Application project.

You need to build a Web application using multiple Web projects? use the Web Application project.

You want to generate one assembly for each page? use the Web Site project.

You prefer dynamic compilation and working on pages without building entire site on each page view? use Web Site project.

You prefer single-page code model to code-behind model? use Web Site project.

Web Application Projects versus Web Site Projects (MSDN) explains the differences between the web site and web application projects. Also, it discusses the configuration to be made in Visual Studio.

Convert a single file aspx to code behind

If manual conversion is too time-intensive, and the automatic conversion isn't working, I think your only other option would be to build your own converter. You could write a simple console app which takes a directory path on the command line and processes every file in that directory. This isn't too hard - here, I'll get you started:

using System;
using System.IO;

class Program
{
    const string ScriptStartTag = "<script language=\"CS\" runat=\"server\">";
    const string ScriptEndTag = "</script>";

    static void Main(string[] args)
    {
        DirectoryInfo inPath = new DirectoryInfo(args[0]);
        DirectoryInfo outPath = new DirectoryInfo(args[0] + "\\codebehind");
        if (!outPath.Exists) inPath.CreateSubdirectory("codebehind");
        foreach (FileInfo f in inPath.GetFiles())
        {
            if (f.FullName.EndsWith(".aspx"))
            {
                //  READ SOURCE FILE
                string fileContents;
                using (TextReader tr = new StreamReader(f.FullName))
                {
                    fileContents = tr.ReadToEnd();
                }
                int scriptStart = fileContents.IndexOf(ScriptStartTag);
                int scriptEnd = fileContents.IndexOf(ScriptEndTag, scriptStart);
                string className = f.FullName.Remove(f.FullName.Length-5).Replace("\\", "_").Replace(":", "_");
                //  GENERATE NEW SCRIPT FILE
                string scriptContents = fileContents.Substring(
                    scriptStart + ScriptStartTag.Length,
                    scriptEnd-(scriptStart + ScriptStartTag.Length)-1);
                scriptContents =
                    "using System;\n\n" +
                    "public partial class " + className + " : System.Web.UI.Page\n" +
                    "{\n" +
                    "    " + scriptContents.Trim() +
                    "\n}";
                using (TextWriter tw = new StreamWriter(outPath.FullName + "\\" + f.Name + ".cs"))
                {
                    tw.Write(scriptContents);
                    tw.Flush();
                }
                //  GENERATE NEW MARKUP FILE
                fileContents = fileContents.Remove(
                    scriptStart,
                    scriptEnd - scriptStart + ScriptEndTag.Length);
                int pageTagEnd = fileContents.IndexOf("%>");
                fileContents = fileContents.Insert(PageTagEnd,
                    "AutoEventWireup=\"true\" CodeBehind=\"" + f.Name + ".cs\" Inherits=\"" + className + "\" ");
                using (TextWriter tw = new StreamWriter(outPath.FullName + "\\" + f.Name))
                {
                    tw.Write(fileContents);
                    tw.Flush();
                }
            }
        }
    }
}

30 minutes coding, 30 minutes debugging. There are some obvious bugs - like, if your code contains a closing script tag anywhere inside, then it won't get exported correctly. The results won't be pretty, but this should take care of 90% of your code, and you should be able to clean up any problem results manually. There, does that help?

Best Answer

Related Solutions

.net – ASP.NET Web Site or ASP.NET Web Application

Website:

Web Application:

Convert a single file aspx to code behind

Related Topic