Once the master page is ready, you can start adding content pages. You do so with the usual Website|Add New Item command, choosing Web Form from the list of Visual Studio templates. Make sure the Select Master Page option is turned on in the Add New Item dialog box. After clicking Add you are asked to select the master page.

The resulting content page, a normal ASPX page, displays one Content control for each content placeholder control on the linked master page. In the designer, the content page also displays the elements, such as text, graphics, and controls, that are defined in the master page. These are grayed out, however, as they cannot be edited from the content page. It's here that you add the custom content to each content page, placing it in the Content controls. While the designer gives you a pretty good idea how the final page will look, I like to use the View in Browser command for a completely accurate rendering.

You can create as many different content pages as you like. Within the navigation structure of the site, it is the content page URLs that you use. When a user navigates to a content page, ASP.Net reads the information in the Page directive that links the content page to its master page. The contents of the master page and the content page are read, combined, and rendered to the client browser.

Control events can be handled in both the master page and the content page. An event must be handled in the page where the control is located. In other words, control events that are raised on the master page are not visible in the content page, and vice versa. Some events are raised in both pages, but separately. These are the Init, Load, and PreRender events.

Programmatically, the master page is considered to be a control on the content page. This permits code on the content page to access properties, methods, and controls on the master page, opening up lots of interesting possibilities. Information contained in the master page, such as control values, can be retrieved by the content page and used as needed. Aspects of the master page itself do not have to be completely static but can change dynamically depending on which content page is open.

For more demanding design tasks, you can nest master pages. This means that a master page can itself be based on another master page. For example, the bottom-level master page could define company-wide page elements that must be present on all pages, while the next level master page could define those elements that are specific to a given department's pages.

Master pages are a valuable tool for the ASP.Net developer. While they are not the only method for including common content across multiple pages, their flexibility and ease of use make them my first choice.