The ASP.NET Web Forms Pageless Architecture (WPA) compiles all page logic into a single DLL. No ASPX files deployed. No scattered templates. One binary, plus your static assets.
But there’s a question that comes up once you start building real pages this way: where do you design?
Building HTML inside C# strings gives you full programmatic control — loops, conditionals, database queries feeding directly into output. But staring at a StringBuilder.Append(@"...") block and trying to visualize how a page will look? That’s not where humans do their best design work.
This article documents a development pattern that emerged from building aspnet-club.com entirely in Pageless Architecture: use ASPX pages as your design workbench, then compile your production pages as C# RequestHandlers into the DLL.
The ASPX file is the sketchpad. The DLL is the deliverable.
The Two Modes of Page Authoring
ASP.NET Web Forms gives you two ways to produce HTML output. Most developers only ever use one.
Mode 1: ASPX Declarative (Visual, Designer-Friendly)
An .aspx file with a Site.master master page. You write HTML directly. You see the structure. Your IDE gives you a design surface, IntelliSense on HTML elements, and instant visual feedback. CSS classes are right there in the markup.
First, the Site.master — this is the page skeleton shared by every child page:
<%@ Master Language="C#" AutoEventWireup="true"
CodeBehind="Site.master.cs" Inherits="System.Site" %>
<!DOCTYPE html>
<html>
<head>
<meta charset='utf-8' />
<meta name='viewport' content='width=device-width, initial-scale=1.0' />
<title>ASP.NET Web Forms Club</title>
<meta name='description' content='ASP.NET Web Forms Open Source Community'>
<!-- Favicon, Open Graph, Twitter meta tags ... -->
<link rel='stylesheet' href='/css/site.css?v=3' />
<link rel='stylesheet' href='/css/markdown-editor.css?v=1' />
<link rel='stylesheet' href='https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.9.0/styles/github.min.css' />
<asp:ContentPlaceHolder ID="head" runat="server"></asp:ContentPlaceHolder>
</head>
<body>
<header class="site-header">
<div class="header-inner">
<a href="/" class="site-logo">ASP.NET Club</a>
<nav class="site-nav" id="siteNav">
<a href="/">Home</a>
<a href="/Forums">Forums</a>
<a href="/Tools">Tools</a>
<a href="/Login">Login</a>
</nav>
</div>
</header>
<main class="site-main">
<asp:ContentPlaceHolder ID="body" runat="server"></asp:ContentPlaceHolder>
</main>
<footer class="site-footer">
<div class="footer-inner">
<p>© 2026 ASP.NET Club, Built with ASP.NET Web Forms</p>
</div>
</footer>
<script src='/js/markdown-editor-component.js'></script>
<script src='/js/security.js'></script>
<script src='https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.9.0/highlight.min.js'></script>
<script>
document.querySelectorAll('textarea.markdown-editor').forEach(function (el) {
MdEditor.init(el);
});
setTimeout(function () {
document.querySelectorAll('pre code').forEach(function (el) {
hljs.highlightElement(el);
});
}, 300);
</script>
</body>
</html>The two <asp:ContentPlaceHolder> tags define the slots — head for page-specific CSS, body for page content. Everything else (navigation, footer, global scripts) is shared.
Now, a child .aspx page plugs its content into those slots:
<%@ Page Title="" Language="C#" MasterPageFile="~/Site.master"
AutoEventWireup="true" CodeBehind="EditorDemo.aspx.cs"
Inherits="System.pages.EditorDemo" %>
<asp:Content ID="Content1" ContentPlaceHolderID="head" runat="server">
<style>
.mde-wrap { display: flex; flex-direction: column; ... }
</style>
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="body" runat="server">
<h1>Markdown Editor Component</h1>
<textarea id="txtEditor" class="markdown-editor"></textarea>
</asp:Content>The child page only contains what’s unique to that page. The master provides everything else. This is where you do your visual design work — the layout, the spacing, the CSS. You open it in a browser, see it render instantly, and iterate.
Mode 2: C# Programmatic (Full Control, Compiles to DLL)
Now the same structure, but in C#. PageTemplate.cs replaces Site.master:
public class PageTemplate
{
public string Title = "";
public string Description = "ASP.NET Web Forms Open Source Community";
public List<string> lstTopCss = new List<string>();
public List<string> lstBottomScript = new List<string>();
public string GenerateHtmlHeader()
{
string encodedTitle = HttpUtility.HtmlEncode(Title);
StringBuilder sb = new StringBuilder();
sb.Append($@"<!DOCTYPE html>
<html>
<head>
<meta charset='utf-8' />
<meta name='viewport' content='width=device-width, initial-scale=1.0' />
<title>{encodedTitle}</title>
<!-- Favicon, Open Graph, Twitter meta tags ... -->
<link rel='stylesheet' href='/css/site.css?v=3' />
<link rel='stylesheet' href='/css/markdown-editor.css?v=1' />
<link rel='stylesheet' href='https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.9.0/styles/github.min.css' />
");
// Page-specific CSS — equivalent of ContentPlaceHolder "head"
foreach (string css in lstTopCss)
sb.AppendLine($" <link rel='stylesheet' href='{css}' />");
sb.Append(@"</head>
<body>
<header class='site-header'>
<div class='header-inner'>
<a href='/' class='site-logo'>ASP.NET Club</a>
<nav class='site-nav' id='siteNav'>
<a href='/'>Home</a>
<a href='/Forums'>Forums</a>
<a href='/Tools'>Tools</a>
<a href='/Login'>Login</a>
</nav>
</div>
</header>
<main class='site-main'>
");
return sb.ToString();
}
public string GenerateHtmlFooter()
{
StringBuilder sb = new StringBuilder();
sb.Append($@"
</main>
<footer class='site-footer'>
<div class='footer-inner'>
<p>© {DateTime.Now.Year} ASP.NET Club, Built with ASP.NET Web Forms</p>
</div>
</footer>
<script src='/js/markdown-editor-component.js'></script>
<script src='/js/security.js'></script>
<script src='https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.9.0/highlight.min.js'></script>
<script>
document.querySelectorAll('textarea.markdown-editor').forEach(function (el) {{
MdEditor.init(el);
}});
setTimeout(function () {{
document.querySelectorAll('pre code').forEach(function (el) {{
hljs.highlightElement(el);
}});
}}, 300);
</script>
");
foreach (string js in lstBottomScript)
sb.AppendLine($" <script src='{js}'></script>");
sb.Append(@"</body>
</html>");
return sb.ToString();
}
}And the child page becomes a RequestHandler — the equivalent of the .aspx child page:
public class MarkdownToHtmlTool
{
public static void HandleRequest()
{
PageTemplate pt = new PageTemplate()
{
Title = "Markdown to HTML",
Description = "Convert markdown to HTML"
};
// Page-specific CSS — same as ContentPlaceHolder "head"
pt.lstTopCss.Add("/css/markdowntohtml.css");
StringBuilder sb = new StringBuilder();
sb.Append(pt.GenerateHtmlHeader());
// Page content — same as ContentPlaceHolder "body"
sb.Append(@"
<h1>Markdown Editor Component</h1>
<textarea id='txtEditor' class='markdown-editor'></textarea>
");
sb.Append(pt.GenerateHtmlFooter());
var Response = HttpContext.Current.Response;
Response.ContentType = "text/html; charset=utf-8";
Response.Write(sb.ToString());
}
}The structural correspondence is exact:
| Site.master | PageTemplate.cs |
|---|---|
Everything above <asp:ContentPlaceHolder ID="body"> | GenerateHtmlHeader() |
Everything below </asp:ContentPlaceHolder> | GenerateHtmlFooter() |
<asp:ContentPlaceHolder ID="head"> | lstTopCss, lstTopScript |
The child page’s <asp:Content> block | The sb.Append(...) calls between header and footer |
Same HTML output. Same navigation. Same footer. Same global scripts. The difference is that PageTemplate.cs compiles into the DLL, while Site.master sits on disk as a file.
The insight is that these aren’t competing approaches. They’re complementary stages of the same workflow.
Designing the Skeleton Itself
The pattern applies to the page skeleton too. When you need to change the site-wide navigation, adjust the footer, or add a new global script reference, you don’t edit PageTemplate.cs directly. You open Site.master, make the change visually, verify it in the browser, then transcribe the update into PageTemplate.cs.
The master file stays in the project as the living design reference for the site skeleton. It never gets deployed to production, but it’s always there when you need to redesign the shared layout.
The Development Workflow
Here’s how a new page gets built in practice:
Step 1: Design in ASPX
Create a new .aspx page. Reference Site.master. Write the HTML structure. Add CSS. Open in browser. Tweak until the layout looks right.
/pages/EditorDemo.aspx ← design workbench
/pages/Site.master ← shared layoutThis is pure visual work. You’re not thinking about database queries or route handling. You’re thinking about how the page should look and feel.
Step 2: Build the RequestHandler
Once the design is settled, create the C# handler. Transcribe the HTML structure into StringBuilder.Append() calls. Add the dynamic parts — database queries, conditional sections, loops.
/engine/RequestHandler/MarkdownToHtmlTool.cs ← production handlerThis is where the C# string-based approach shines. A forum page that loops through tags from a database and conditionally shows moderator controls? That’s natural in C#:
foreach (var tag in allTags)
{
if (tag.Visibility == 1)
{
sb.Append("<button class='forums-tag' data-tag='" +
HttpUtility.HtmlAttributeEncode(tag.Name) + "'>" +
HttpUtility.HtmlEncode(tag.Name) + "</button>");
}
}Try doing that in declarative HTML without a template engine. In C#, it’s just a foreach and an if.
Step 3: Register the Route
Add one line to the routing table in Global.asax.cs:
case "/markdowntohtml":
RH.MarkdownToHtmlTool.HandleRequest();
return;Done. The page is live.
Step 4: Keep the ASPX as Reference
The .aspx file stays in the project under /pages/. It never gets deployed. It never runs in production. But it’s there when you need to redesign the page — you open the ASPX, adjust the layout visually, then update the C# handler to match.
Why String-Based HTML in C
The immediate objection: isn’t building HTML in C# strings messy?
For pure layout work — yes. That’s why you design in ASPX first. But for the production page that includes programmatic logic, the C# approach has real advantages:
Loops and conditionals are native C#. No template syntax to learn. No @foreach or {% for %} or {{#each}}. Just C#.
Database queries feed directly into output. Open a connection, query, loop through results, append HTML. No model-binding layer, no ViewModel, no data context.
The entire page is in one file. The HTML structure, the data access, the conditional logic — all visible in one scroll. No jumping between a .cshtml template and a controller and a model.
It compiles. Typos in variable names get caught at build time. A misspelled property in a Razor template silently renders nothing. A misspelled property in C# fails to compile.
It’s debuggable. Set a breakpoint anywhere in the handler. Step through the HTML generation line by line. Inspect the StringBuilder content at any point.
Single-DLL Deployment
The payoff for this entire pattern is deployment simplicity.
Your production server receives:
/bin/aspnet-club.dll ← all page logic, all handlers, all routing
/css/site.css ← static assets
/css/markdown-editor.css
/js/markdown-editor-component.js
/js/forums-new.js
/media/... ← images
Web.config ← IIS configuration
Global.asax ← entry point (tiny, rarely changes)No .aspx files. No .master files. No template files. The DLL contains every page the site can serve.
To deploy an update: compile, copy the DLL, done. IIS picks up the new binary automatically. The old application domain unloads, the new one loads. Zero-downtime deployment for a single-server setup.
Compare this to deploying a traditional Web Forms site where you’re copying dozens of .aspx and .master files alongside the DLL. Or a .NET Core site with its publish folder containing hundreds of files across multiple directories.
When ASPX Still Wins
This pattern doesn’t replace ASPX entirely. There are cases where keeping a page as a live ASPX makes sense:
Rapid prototyping. When you’re still figuring out what the page should be, the ASPX feedback loop is faster than the compile-and-test cycle of a C# handler.
Static content pages. A simple “About” page with no dynamic content might not justify a full RequestHandler class. An ASPX file is fine.
Designer collaboration. If someone else is working on the visual design, an ASPX file is more approachable than C# string blocks.
The pattern works best for pages with significant dynamic content — forums, user profiles, dashboards, tools — where the programmatic control of C# earns its keep.
The Bigger Picture
What makes this pattern possible is something unique to ASP.NET Web Forms: the platform gives you both a visual design surface and a programmatic HTML generation pipeline, and they produce the same output. You’re not switching between two different rendering engines. You’re switching between two ways of authoring the same HTML.
Site.master and PageTemplate.cs generate the same skeleton. An .aspx child page and a RequestHandler class produce the same content. The HTML that reaches the browser is identical regardless of which authoring mode produced it.
That’s the architectural insight: ASPX is the design surface, C# is the production engine, and both speak the same language — raw HTML.
No other major web framework offers this exact combination. Razor pages don’t have a visual design surface. PHP templates don’t compile into a single binary. Node.js template engines don’t share a common output format with a compiled alternative.
ASP.NET Web Forms, used this way, gives you the best of both worlds: visual design when you need it, compiled deployment when you ship it.
Skipping F5: Live Development with Local IIS
During development, most Visual Studio developers press F5 to launch IIS Express, wait for the browser to open, test, stop, edit, F5 again. This cycle adds friction — especially for front-end work where you’re tweaking CSS or HTML and just want to see the result.
There’s a faster way. Windows has a full IIS server built in. You can point it directly at your project’s source folder and it will serve your application continuously — no F5 required.
The setup is straightforward: open IIS Manager, create a new website, and set the physical path to your project folder (the one containing Web.config). Assign it a port, set the application pool to .NET v4.0, and it’s running.
From that point on, your workflow becomes: edit code, press Ctrl+Shift+B to build, switch to the browser, refresh. The DLL recompiles into the bin folder, IIS detects the change and recycles the application domain automatically. No launch delay, no browser re-opening, no waiting for IIS Express to spin up.
For front-end changes — CSS, JavaScript, HTML in ASPX design files — you don’t even need to build. Just save the file and refresh the browser. IIS serves the static files directly from your project folder.
This pairs naturally with the ASPX-as-workbench pattern. You have your design .aspx file open in Visual Studio, the browser open side by side pointing at http://localhost:8080/pages/EditorDemo.aspx, and every save is instantly visible. The feedback loop drops from “F5 → wait → test → stop → edit” to just “save → refresh.”
When you do need to step through code with breakpoints, F5 debug mode is still there. Attach to the IIS worker process, or just hit F5 as usual — Visual Studio will launch its own debug session alongside the already-running IIS site. The two don’t conflict.
This is a small setup step that permanently eliminates the most common friction point in Web Forms development.
This article is part of a series on ASP.NET Web Forms Pageless Architecture. The pattern described here is used in production at aspnet-club.com.