In the .NET ecosystem, the term "component" carries a precise technical meaning—distinct from generic usage like "software module" or "library." Here, a component refers specifically to any type that implements System.ComponentModel.IComponent, either directly or through inheritance. This interface forms the foundation for design-time support, visual tooling integration, and lifecycle-aware resource management.

The IComponent Contract

The IComponent interface extends IDisposable and introduces two key members:

public interface IComponent : IDisposable
{
    event EventHandler Disposed;
    ISite Site { get; set; }
}

This minimal contract signals that an object participates in the .NET componetn model. The Disposed event enables deterministic cleanup notifications, while the Site property establishes a contextual binding—linking the component to its container and enabling service discovery.

The framework provides System.ComponentModel.Component as the canonical base implementation. Most built-in components—including Timer, BackgroundWorker, and ImageList—derive from it.

Components vs Controls

All Windows Forms controls (e.g., Button, Label, Form) inherit from Control, which itself inherits from Component. Thus, every control is a component—but not every component is a control.

• Components are non-visual, service-oriented types focused on behavior and composition (e.g., timers, data sources).
• Controls are visual components with rendering logic, window handles, and message processing via WndProc.

This hierarchy enables unified disposal patterns and design-time extensibility across both categories.

The Container-Service Architecture

Components rarely exist in isolation—they operate within a IContainer, an abstraction representing logical grouping and service provisioning:

public interface IContainer : IDisposable
{
    void Add(IComponent component);
    void Add(IComponent component, string name);
    void Remove(IComponent component);
    ComponentCollection Components { get; }
}

Unlike collection-based containers (List<T>, Queue<T>), IContainer does not store data—it manages relationships and enables inter-component communication via services.

The ISite interface bridges this relationship. When a component is added to a container, its Site property is assigned an instance that holds references to both the component and its container—and crucially, implements IServiceProvider:

public interface IServiceProvider
{
    object GetService(Type serviceType);
}

This allows components to request capabilities dynamically: GetService(typeof(ISelectionService)), GetService(typeof(IDesignerHost)), etc.

Design-Time vs Runtime Behavior

A component’s behavior changes depending on its execution context:

• Design-time: The component resides in a visual designer (e.g., Visual Studio’s Form Designer). Its DesignMode property is true, and it can safely call GetService to interact with IDE services.
• Runtime: The component executes inside a running application. DesignMode is false, and service requests return null unless custom infrastructure is provided.

Conditional logic based on DesignMode is common—for example, drawing version watermarks during design but omitting them at runtime:

protected override void OnPaint(PaintEventArgs e)
{
    base.OnPaint(e);
    e.Graphics.DrawRectangle(Pens.Blue, new Rectangle(0, 0, Width - 2, Height - 2));

    if (DesignMode)
    {
        using var font = new Font("Arial", 10);
        e.Graphics.DrawString("v2.30.109.1302", font, Brushes.Blue, new PointF(5, 5));
    }
}

Custom Control Development Strategies

Three primary approaches exist for extending UI functionality:

1. Composite Controls: Aggregate existing controls (e.g., deriving from UserControl). Ideal for layout-heavy scenarios.
2. Extended Controls: Inherit from standard controls (e.g., Button) to augment behavior or appearance without rewriting core logic.
3. Custom Controls: Derive directly from Control for full rendering and message-handling control—requiring manual OnPaint and WndProc overrides.

Each strategy respects the same component contract and supports both design-time and runtime modes.

Visual Studio’s Form Designer as a Container

The Form Designer is itself an IContainer implementation. Dragging a Timer onto a form invokes container.Add(timer), assigning it a Site and enabling access to design-time services. This architecture powers features like automatic ImageList population in property grids and selection-change notifications.

For example, a custom label that displays current selection count in the designer:

protected override void OnHandleCreated(EventArgs e)
{
    var selectionSvc = GetService(typeof(ISelectionService)) as ISelectionService;
    if (selectionSvc != null)
    {
        selectionSvc.SelectionChanged += (_, __) => 
        {
            var svc = GetService(typeof(ISelectionService)) as ISelectionService;
            if (svc != null)
            {
                Text = $"Selected: {svc.SelectionCount} | Primary: {svc.PrimarySelection?.GetType().Name}";
            }
        };
    }
    base.OnHandleCreated(e);
}

This code runs only during design-time—highlighting how tightly coupled the component model is with IDE tooling.