100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
.NET Framework

User Controls

Learn how ASP.NET Web Forms user controls (.ascx) let you package reusable markup and code-behind logic into components shared across pages.

Web Forms ControlsIntermediate9 min readJul 10, 2026
Analogies

Building Reusable UI with User Controls

A user control is a reusable fragment of markup and code saved with an .ascx extension, combining a subset of Web Forms syntax with its own code-behind class, that can be dropped onto multiple pages the way a custom widget would be. Unlike a full page, an .ascx file has no html, head, or body tags and cannot be requested directly by a browser; instead it's registered on a host page with an @ Register directive and then declared as a tag, becoming a self-contained, reusable building block for things like a login panel, a shopping-cart summary, or a search box repeated across many pages.

🏏

Cricket analogy: A user control is like a reusable graphics overlay template a broadcaster drops onto multiple channels' coverage — the same 'strike rate widget' appears in both the T20 highlights show and the live match feed.

Creating and Registering a User Control

A user control is authored with @ Control instead of @ Page at the top of its .ascx file, exposes public properties and methods in its code-behind for the host page to configure, and can raise custom events, such as a Search button's Click event, that the host page subscribes to just like any server control's event. To use it, the host page adds an @ Register directive specifying a TagPrefix, TagName, and Src pointing at the .ascx file, then places an instance using that tag, optionally setting the exposed properties as attributes, exactly as it would configure a built-in control like asp:TextBox.

🏏

Cricket analogy: Exposing a public 'PlayerName' property on a user control is like configuring the same graphics widget differently per broadcast — setting it to 'Kohli' for one match and 'Root' for another, reusing the same underlying overlay.

aspx-csharp
<%-- SearchBox.ascx --%>
<%@ Control Language="C#" AutoEventWireup="true" CodeFile="SearchBox.ascx.cs" Inherits="SearchBox" %>
<div class="search-box">
    <asp:TextBox ID="txtQuery" runat="server" />
    <asp:Button ID="btnSearch" runat="server" Text="Search" OnClick="btnSearch_Click" />
</div>

<%-- SearchBox.ascx.cs --%>
public partial class SearchBox : System.Web.UI.UserControl
{
    public event EventHandler<SearchEventArgs> SearchRequested;

    public string Placeholder
    {
        get { return txtQuery.Text; }
        set { txtQuery.Text = value; }
    }

    protected void btnSearch_Click(object sender, EventArgs e)
    {
        SearchRequested?.Invoke(this, new SearchEventArgs(txtQuery.Text));
    }
}

<%-- HostPage.aspx --%>
<%@ Register TagPrefix="uc" TagName="SearchBox" Src="~/Controls/SearchBox.ascx" %>
<uc:SearchBox ID="searchBox1" runat="server" OnSearchRequested="searchBox1_SearchRequested" />

User Controls vs. Custom Server Controls

User controls are the fastest way to reuse markup-plus-logic within a single application because they're written almost exactly like a page, but they can't be shared across projects as a compiled component and are tied to declarative .ascx markup. A custom server control, by contrast, is compiled into a DLL, has no markup file at all (its output is built entirely in C# by overriding Render or composing child controls), and can be added to the Visual Studio Toolbox and distributed as a NuGet package for reuse across many unrelated applications, at the cost of more code to write and a compile step for every markup tweak.

🏏

Cricket analogy: A user control is like a franchise's in-house training drill reused only within that team's academy, while a custom server control is like a certified BCCI coaching module shared and reused across every franchise's academy.

A quick rule of thumb: reach for a user control when the reusable UI lives entirely inside one application, and reach for a custom server control only when you need to distribute the component as a compiled, markup-free package across multiple, unrelated projects.

  • A user control (.ascx) combines markup and code-behind into a reusable fragment, authored with @ Control.
  • User controls cannot be requested directly by a browser and have no html/head/body tags.
  • A host page registers a user control with @ Register (TagPrefix, TagName, Src) and declares it as a tag.
  • User controls can expose public properties and raise custom events for the host page to consume.
  • Custom server controls compile to a DLL with no markup file and can be distributed across projects, unlike user controls.
  • User controls are the fastest route to reuse within a single app; custom server controls suit cross-project distribution.
  • Both approaches integrate into the normal page lifecycle and support ViewState like any other server control.

Practice what you learned

Was this page helpful?

Topics covered

#NETFramework#ClassicASPNETWebFormsWebPagesStudyNotes#MicrosoftTechnologies#UserControls#User#Controls#Building#Reusable#StudyNotes#SkillVeris