ASP.NET Master Page Use

Master pages separate content from templates.

You can use master pages along with code-behind in your ASP.NET website. Master pages can be combined with code-behind in the C# language to simplify and ease maintenance of your complex site.

Intro. First, I use the Website project type in Visual Studio. This is recommended as it is a simpler and more streamlined project type. With a Web Application project, you may need to navigate slightly different menus and dialogs.

Visual Studio

The master page serves as a template for the other content pages on the site. The master page has some code-behind methods, and it could auto-generate the page titles for the pages and some H1 headers for each content page.

Master page: Stores global page elements that occur on every content page.
Extension: ".Master".

Content page: Stores page-specific elements that are put into the master.
Extension: ".aspx".

Master page code-behind: Can change master page after it acquires content. Extension: ".aspx.cs".

Navigation and styles. The master page also might contain a TreeView for navigation and a footer with your contact info. It uses markup for the site layout, and contains some CSS styles and JavaScript code.

Tip: You can use inline CSS in your master page, for an alternative to an external style sheet.

Images and scripts. Your site's logo is a perfect thing to put in your master page. You can also put code such as Google Analytics, which is implemented as a small piece of JavaScript.

Steps. To start, go to the Website menu in Visual Studio, and then add a new item. Master Page will appear in that list, so just select it and proceed as normal. You should be familiar enough with Visual Studio to do this quickly.

The ContentPlaceHolder markup tag is where content page content is inserted into each page. So, now we want to make some content pages. How do we do that? Now, look at your new master page file. You will see some tags in the master page.

ContentPlaceHolder markup

<asp:ContentPlaceHolder ID="MainContent" runat="server" />

Content pages are made in the same way as master pages. Go to the Website menu, then add new item, and select Web Form. That's another term for "Content Page". Check the "Select Master Page" checkbox and finally select your master page.

Next, I want to show an example of a content page and walk you through some parts of it. You should now have a content page. And it will have some special initial markup. It will contain several lines of markup similar to the following.

Contents of master page file: .Master

<%@ Page Language="C#" MasterPageFile="~/DotNetPerls.Master" Title="Untitled Page" %>

<script runat="server">

</script>

<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
</asp:Content>

Final steps. In the master page, you can change various elements picked up from content pages in the code-behind. The master page transforms itself and takes on the properties of the content pages.

Then: You can use code in the master pages to change parts of the master page that were retrieved from the content pages.

Class that uses MasterPage base class: C#

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Web;
using System.Web.UI;

public partial class _Default : MasterPage
{
    protected void Page_Load(object sender, EventArgs e)
    {
	this.Page.Title = "Your Site: " + this.Page.Title;
    }
}

Drawbacks. Master pages have drawbacks. We start with performance problems. A master page will result in another assembly in your project in many settings. This is a burden. In my experience removing master pages has resulted in better performance.

Inheritance. Master pages are confusing because they do not inherit as you might think they should. For a content page to access object data based on the master page, it must take a confusing route and use Master.Page.FindControls().

Next: Here's some code that shows how to change the value of a TextBox when using a master page.

Reference ASP.NET Master Page: MSDN

Content page: C#

// How content page can change TextBox.
TextBox mpTextBox = mpContentPlaceHolder.FindControl("TextBox1") as TextBox;
if (mpTextBox != null)
{
    mpTextBox.Text = "TextBox found!";
}

Regular page: C#

// How regular page can change TextBox.
TextBox1.Text = "TextBox found";

Alternative without master pages. Why do we need to use FindControl here? Because the content page is a sibling, not a child of the master page. It cannot access the control directly.

IntelliSense: This is a powerful programming "helper" in Visual Studio that tells you whether something exists and what it is.

And: In the second example above, IntelliSense will work and tell you that the TextBox exists. In content pages, it will not.

Cache. You want a site-wide caching scheme, but master pages will not let you specify it there. You must separately change the cache settings of each content page. This becomes less practical as your site grows.

OutputCache

Cache directive example

<%-- Can't put on master page. --%>
<%@ OutputCache Duration="600" VaryByParam="file" %>

Discussion. A good use of a content page that uses a master page is to have one for the "contact us" or "about us" page. However, if your business grows a lot, you might need ten contact pages. You then have ten more source files.

Content versus code. This is the most severe drawback of master pages. If a website has any significant data, it must enforce a clear separation between data and code. Content pages allow embedded code in data.

But: The result is a site that is slow and complicated. It's better to consolidate your logic together, and separate your data.

Data separation. Master pages do work better with fewer content pages. However, the whole point of content pages is to have content. They also always allow code, which confounds the programming model of content/code separation.

And: You could more easily avoid the master page, and use logic to change parts of the page.

Summary. We looked at master pages in the C# programming language and ASP.NET web development framework. We dynamically generated pages. This leads to fewer typos, with less content to manage. Code-behind separates complex logic from page markup.