When to Use Each Type of Control

With composite controls and User control having so many similarities, there seems to be some redundancy in the framework. Since User controls have such an affinity with the designer, perhaps it seems you don't need custom composite controls at all. However, each style of composite controls has distinct advantages and disadvantages.

The biggest advantage of custom composite controls is that they are deployed as individual assemblies. Because custom composite controls are packaged in distinct assemblies, you may sign them and deploy them across the enterprise. You also may install them in the Global Assembly Cache. The primary downside to using custom composite controls is that they require more attention to detail in the coding process (there's no designer support).

The primary advantage to User controls is that they do include designer support. That makes them very easy to design visually. However, User controls have a downside in their deployment-they go with the project in which they were created, and they are deployed that way. You can include them as part of other projects, but that requires copying the ASCX and the CS files to the new project. They are not deployed as signed, secure assemblies.


This look at composite style controls wraps up ASP.NET's custom control story. Composite controls are a great way to package UI functionality into manageable chunks. Custom composite controls and User controls both maintain internal lists of controls and render them on demand. However, custom composite controls live entirely within an assembly, whereas User controls are split between ASCX files and a backing source code file and/or assembly.

In the next tutorial, we'll take a look at some of the other more extensive controls available within ASP.NET.