ASP.NET Custom Controls are compiled into a dll. At first you might look for the Project that creates a web custom control under the "Visual C# - Web" in the New Project dialog box. But the project template for creating a new custom control is under Visual C# - Windows. Name of this project template is "Web Control Library".

By default the name you choose for the project also becomes the name for your custom control dll. Name of this dll can be changed by changing the Assembly Name in the Properties box for this project.

Changes

Also, a class (WebCustomControl1) for the custom control is created in the file WebCustomControl1.cs. You need to change both these to the name of custom control you want to create. Visual Studio 2005 lets you automatically change the name of the class when you change the name of the file. You need to change the ToolboxData attribute of this newly created class as well. This attribute defines the entry in the source file when you drag and drop this control from the Visual Studio toolbox.

When you created a new web control project, Visual Studio also adds a public property called Text. You can probably keep this and extend it as needed. Most of the controls do expose a property called Text. A few attributes have been added to this property as well.

The two properties to note here are Category("Appearance") and DefaultValue(""). When a developer drags and drops this control from the toolbox onto a form design surface, above attributes are used in showing this property in the Properties window. In this case, the Text property will shown under the category Appearance with an empty value in the Properties widow in Visual Studio.

One other interesting thing to note here is that the value you set to the Text property is stored in the ViewState and the value is obtained from the ViewState when you use get. This way the state (various properties) of a given control is maintained and these property values don’t get lost when the data is post back to the server. So, at the beginning (after a couple of changes), your custom control code will look like this:

namespace Tagger
{
    [DefaultProperty("Text")]
    [ToolboxData("<{0}:TagEntry runat=server></{0}:TagEntry>")]
    public class TagEntry : WebControl
    {
        [Bindable(true)]
        [Category("Appearance")]
        [DefaultValue("")]
        [Localizable(true)]
        public string Text
        {
            get
            {
                String s = (String)ViewState["Text"];
                return ((s == null) ? String.Empty : s);
            }
            set
            {
                ViewState["Text"] = value;
            }
        }

        protected override void RenderContents(HtmlTextWriter output)
        {
            output.Write(Text);
        }
    }
}

Four Pieces

There four distinctly different logical pieces here:

Assembly Name : Name of the dll (the dll you would use in other web projects or give to other application developers). Example: tagger.dll
Namespace : You would put all the code you write for this custom control (or these custom controls) under this namespace to avoid any collisions with names from other projects. Example: namespace tagger { ... }
Name of class file : This C# class file contains the code for custom control. Of course, there can be multiple files. Example: WebCustomControl1.cs or Tagger.cs
Name of the class : This is the actual class that holds a custom control. You can have multiple classes, one for each custom control as well. Example: public class WebCustomControl1 or public class Tagger

If you are writing just one custom control in this assembly, it would make sense to name all the above four name. So, for example, the Tagger assembly is Tagger.dll binary file which is compiled from the Tagger.cs code file which has all of its code under the Tagger namespace and there is just class named Tagger.