Datasheet

all of your development without the benefit of a drag-and-drop designer). As you’ll see in this book, all

the features that you can take advantage of in a custom control are available to you in a user control —

it’s just that the user control’s drag-and-drop designer means that you don’t need them.

The second major limitation of user controls is in their reusability: user controls can’t be shared among

projects or Web sites. A user control can be used only on Web pages in the project that the user control is

part of. There is no way around this limitation.

Custom Controls

Custom controls are a more code-intensive way to create reusable components for Web applications. For

instance, to add new controls to your custom controls, you must write code that will create the controls

and add them to the Controls collection of your custom control — there is no drag-and-drop facility as in

a user control. In return for taking longer to create, custom controls offer you more power.

Custom controls are more flexible than user controls. You can create a custom control that inherits from

another server-side control and then extend that control. You could, for instance, create a custom control

based on another custom control— even one as complex as the TreeView control — and then add new

methods or properties to create your own, even more powerful control.

Custom controls are more reusable than user controls. You can share a custom control among projects.

Typically, you’ll create your custom control in a Web Custom Control library that is compiled separately

from your Web application. As a result, you can add that library to any project in order to use your custom

control in that project.

Web Parts

It’s not really correct to compare Web Parts with user controls and custom controls. User controls and

custom controls can be used as Web Parts, although they will lack all of the features of a full-fledged Web

Part. But, if you want to take full advantage of the Web Part feature set, then you must build your control

as a Web Part right from the beginning. As you’ll see, Web Parts are an extension of custom controls—

think of full-fledged Web Parts as custom controls with superpowers.

Web Parts actually first appeared not in ASP.NET but in Windows SharePoint Services (in 2003, when

SharePoint was re-architected to run on top of ASP.NET). SharePoint is Microsoft’s Web-based tool for

creating document-based solutions that can be customized by the user. As part of visiting a SharePoint

site, users can build pages in SharePoint by adding Web Parts to a SharePoint page or modifying the

Web Parts already on the page. With ASP.NET 2.0, a version of Web Parts was added to ASP.NET.

For most developers, the statement that “users can build pages in SharePoint” seems counterintuitive.

The usual division of labor is to have developers build Web pages and users . . . well, users just use the

pages. SharePoint, however, was designed to empower users, to let users build the pages they needed

without having to call on the IT staff. In ASP.NET, Web Parts can be used to fulfill the same function: to

let users build the pages they need from the inventory of Web Parts available to a page. Because of this

ability, Web Part developers have a new and more interesting job to do. Web Part developers don’t just

build applications; they build components that enable users to build applications.

Creating Your Own Controls

05_57860x ch01.qxd 10/4/05 9:26 PM Page 5