ASP.NET Control Designers Overview
ASP.NET includes enhanced support for creating designers for Web server controls. Designers enable you to build a design-time user interface (UI) for a control, so that developers can configure your control's properties and content in a visual design tool such as Visual Studio. For background information about the design-time architecture and features provided by the .NET Framework, see Extending Design-Time Support.
This introduction explains the features of ASP.NET control designers, basic designer classes and their functionality, and scenarios for working with designers.
While ASP.NET continues to support the control designer architecture from the earlier versions, it has added significant improvements.
Region-based editing. Regions are editable areas in the design-time view of a control. This feature offers WYSIWYG editing of a control's contents at design time.
Action lists. Action lists are menus of tasks that the page developer of a control can use in the design-time UI. For example, the design-time view of your control could provide a menu of available tasks, including a task to format the control automatically.
Data source and data-bound designers. Data source control designers allow the page developer to configure data source controls. Data-bound control designers allow the page developer to configure data-bound controls. Features are available to implement cross communication between the data source and data-bound designers. For an example of a data source control designer, see DataSourceDesigner. For an example of a data-bound control designer, see HierarchicalDataBoundControlDesigner.
Simplified template editing. The model for creating a UI for design-time editing of templated controls (such as GridView) has been drastically simplified and modified so that the control developer can choose to perform his or her own template editing with regions. For an example, see Templated Server Control Example.
Simplified object model. The object model for working with design-time rendering is simplified, so that the only significant issue a developer has to be concerned with is producing design-time HTML. Several new base classes provide access to the simplified object model: ControlDesigner, ContainerControlDesigner, and CompositeControlDesigner.
Subscription to host services. A control designer can subscribe to and use various services provided by the host environment. For example, a control designer can use Visual Studio 2005 services to provide access to data, provide access to configuration, add controls to a page programmatically at design time, handle click events in the designer, paint on the design surface, and access other services such as designer-state.
A control designer enables design-time rendering for a Web server control by acting as a mediator between the run-time control and the host environment. Within the host environment, designers provide the following functionality to help you create a design-time UI for users of your controls:
Design-time rendering and content. A control designer enables multiple kinds of rendering, both simple and complex. Region-based editing and template editing are examples of the kinds of design-time UI you can provide for a control. You can also provide column editing or multiple run-time views on a control, so a developer working with the control at design time can choose from a set of options as to how the control is rendered at run time.
Other design-time classes. Besides the designer classes, there are type converter classes that associate with a type or property and perform type conversions (such as string-to-value). There are also UI type editor classes that provide a specialized UI for editing a property. For example, the color picker drop-down list in a property grid enables you to select a color for a color property on a Web control. You can also create a specialized component editor, which is a class that provides editing for the properties of a control as a whole.
Persistence of the associated control's data. The inner properties and content of a control can be persisted, so that the control and its child controls maintain state in the design-time environment. This is controlled by how the configured control is defined in the markup.
When you create control designers for your Web server controls, there are several base classes you are likely to use:
Base class that provides design-time support for Web server controls.
Base class for a simple containment control that provides editing for a control's collection of child controls. This designer provides one editable region for free, and the host (such as Visual Studio 2005) provides all rendering automatically.
Base class that provides design-time support for rendering composite Web server controls. It provides programmatic control over the rendering of child controls as well.
These base classes provide design-time support for data source and data-bound controls. They are designed to communicate with each other.
Scenarios for Working with Designers
There are two common scenarios in which you might work with control designers: developing custom controls, and developing visual design tools.
If you develop custom Web server controls, you can create an associated designer to enhance a page developer's ability to configure the control at design time. This scenario is especially useful if your control might be reused by a number of page developers. For example, you might create a custom chart control. If you provide an associated control designer, different intranet page developers could each configure a control on a page with a different style.
If you develop a visual Web design tool, similar to Visual Studio 2005 or Microsoft FrontPage, you can utilize the control designer hosting components. This enables your tool to provide services and interact with control designers, in order to provide design-time rendering for custom controls.
For more information about the .NET Framework designer architecture, see Design-Time Architecture. For details on creating your own designer for a custom Web server control, see Walkthrough: Creating a Basic Control Designer for a Web Server Control. For details on creating a custom control designer with services and action lists to provide a design-time user interface (UI), see Sample Control Designer with Action Lists and Services.
Securing a Custom Control Designer
When a control is in design view, the designer component processes property changes and renders markup in the design host (for example, Visual Studio). At design time, the designer component of a control runs with the same level of trust as its design host. Designer components can potentially access databases, make calls to Web sites on a remote server, create and write files to the developer's computer, send e-mail messages, and execute code in other assemblies.
The information in this section describes best practices that will help you improve the security of the control designer features.
In addition to following coding and configuration best practices to help improve the security of an application, make sure that you continually keep the application server up to date with the latest security updates for Microsoft Windows and Internet Information Services (IIS). You should also make sure that you have the latest releases of any commercial custom-control packages that you have installed on your computer.
You can find more detailed information about best practices for writing secure code and for securing applications in the book "Writing Secure Code" by Michael Howard and David LeBlanc. For additional guidance, see the Microsoft Patterns and Practices Web site and Guidelines and Best Practices.
Security Issues for Custom Control Users
You should be aware that custom controls from unknown sources might contain designers that expose sensitive data from your computer to the Web, or that run malicious code at design time. You cannot use code access configuration to limit access for control designers, because they must always run in the design host with full trust. For more information about trust levels, see ASP.NET Trust Levels and Policy Files. For more information about Code Access Security, see Introduction to Code Access Security.
Security Issues for Custom Control Developers
Using configuration attributes for classes and members to limit permissions to the minimum level required for the control's functionality is not a sufficient security measure for designer components, because they must run in the design host with full trust.
If possible, do not use live data from a database to display example structures for previews of data controls, such as the GridView control. This can expose potentially sensitive data from the database. Instead, use example data structures to build data for previews.
Security Issues for Design Host Developers
If you develop a design host (such as Visual Studio), you should check HTML markup, text, and other data returned from the designer for security risks before you display it. In addition, limit the size of HTML markup strings and designer regions to manageable dimensions. For more information about HTML validation, see Validating User Input in ASP.NET Web Pages
Supporting Multiple Development Tools
Microsoft Visual Web Developer supports all the features discussed in this topic, but other developer tools might not. Some examples of features that might not be supported are:
Regions. Control developers can examine the SupportsRegions property and modify the behavior of the control designer appropriately.
Host services. Control developers can examine the return value of the GetService method before using the service. For an example, see How to: Use Services and Action Lists with Control Designers.
Region collections. Both versions of the GetDesignTimeHtml method should be overridden, as some development tools do not support region collections.