C# 4 and .NET 4

1192 ❘ ChaPTer 41 Asp.net feAtures
Custom Controls
Custom controls go a step beyond user controls in that they are entirely self-contained in C# assemblies,
requiring no separate ASP.NET code. This means that you don’t need to go through the process of
assembling a user interface (UI) in an .ascx file. Instead, you have complete control over what is written to
the output stream, that is, the exact HTML generated by your control.
In general, it will take longer to develop custom controls than user controls because the syntax is more
complex, and you often have to write significantly more code to get results. A user control may be as simple
as a few other controls grouped together, as you have seen, whereas a custom control can do just about
anything short of making you a cup of coffee.
Creating and referencing Custom Controls
To get the most customizable behavior for your custom controls, you can derive a class from
System.Web.UI.WebControls.WebControl. If you do this, you are creating a full custom control. Or,
you can extend the functionality of an existing control, creating a derived custom control. Finally, you can
group existing controls together, much as you did in the last section but with a more logical structure, to
create a composite custom control.
Whatever you create can be used in ASP.NET pages in pretty much the same way. All you need to do is
place the generated assembly in a location where it can be found by the web site or application that uses it,
and register the element names to use with the directive. For this location, you have two
options: you can either put the assembly in the bin directory of the web site or application, or place it in the
GAC if you want all web sites and applications on the server to have access to it. Or, if you are just using
a user control on a single web site, you can just put the .cs file for the control in the App_Code directory
for the site.
The directive takes a slightly different syntax for custom controls:
You use the TagPrefix option in the same way as before, but you don’t use the TagName or Src attributes.
This is because the custom control assembly you use may contain several custom controls, and each of
these will be named by its class, so TagName is redundant. Plus, because you can use the dynamic discovery
capabilities of the .NET Framework to find your assembly, you simply have to name it and the namespace in
it that contains your controls.
In the previous line of code, you are instructing the program to use an assembly called
PCSCustomWebControls.dll with controls in the PCSCustomWebControls namespace, and use the
tag prefix PCS. If you have a control called Control1 in this namespace, you could use it with the
ASP.NET code:
The Assembly attribute of the directive is optional — if you have custom controls in the
App_Code directory of your site, you can omit this, and the web site will look at code here for controls. One
thing though — the Namespace attribute is not optional. You must include a namespace in code files for
custom controls, or the ASP.NET runtime will not be able to find them.
With custom controls, it is also possible to reproduce some of the control nesting behavior that exists in list
controls, for example the way that you can nest controls inside a list control to populate
the list control:
The Happy Room
The Angry Room
The Depressing Room
The Funked Out Room
www.it-ebooks.info