Knowledge of building ASP.NET User Controls
Knowledge of building ASP.NET Server Controls
As we all know, both User Controls and Server Controls have their pros and cons. User controls are as easy to write as ASP.NET web forms and can be reused across your ASP.NET web application or website. Server Controls on the other hand, are a bit more difficult to write, however, unlike User Controls, which can be reused across one website or web application, Server Controls can be bundled up in an assembly and be reused across multiple web applications and websites.
As mentioned above, User Controls are fairly easy to write. You can begin writing them just as you would a regular web form. You can set output caching on them to achieve fragment output caching (output caching portions of your website). Let's say you have a Repeater Control that populates a list of users that your website wants displayed. You might want to use this Control in several pages. For example, you might want to display it in an Administration page, to show the amount of users you have signed up, or on a dashboard, allowing executives to view these users and the number of times they logged in. This case would call for a User Control, because otherwise, you would have to rewrite the code multiple times, and that would mean that each change would have to be applied multiple times.
Server Control content is achieved by adding C# code and having it render on the page, unlike a web form, which would take a few simple XML elements. Again, looking at the example above, what if your Administration and Dashboard pages are on two different websites though? You could achieve this by writing the code once inside of a Server Control and then reusing this same control across these sites. Here's the caveat: Developing a repeater in code is by no means an easy task. In fact, some would even sacrifice the benefits due to the effort.
The best of both worlds
You guessed it, there's a way to write a User Control inside of an assembly and share it across multiple web sites or web applications. Here are the abstract steps we will follow and then we will go through a full walk-through with screenshots to ensure everything is understood clearly. Essentially, we will:
Create a class library.
Add a text file to this class library and change its extension to .ascx (changing the extension is not necessary, but it does help eliminate confusion).
Add a class that will serve as our code behind, which will have a .cs extension.
Add another class that will serve as our designer and we will give it an extension of .designer.cs (we will explain why we are following this step).
Make our .ascx file an embedded resource to be able to read its contents from our classes.
Use the System.Web.UI.Page class' ParseControl property to read the contents of the .ascx file and convert it to a Control object.
Although this may seem like a lot to go through to achieve this task, it really isn't. Also, you will get used to it and it will become second-nature. One thing we can't argue about though, is that this method is the fastest way and easiest way of developing a control that can be used across multiple websites and web applications.
Step 1 - Create a new solution and add a class library
Figure 1 - Creating a new solution and adding a class library
Step 2 - Add a text file to your class library and change its extension to .ascx
Figure 2 - Adding our .ascx file
Step 4 - Make our "code-behind" file a partial class and inherit from WebControl in order to make it a custom Server Control
public partial class UserRepeaterControl : WebControl
Code 1 - Our code-behind file
Step 5 - Add our designer file
Before we jump into this screenshot, we are adding this file because of the way Visual Studio handles adding User Controls and Web Forms. In the good ol' days of ASP.NET 1.1, every control that you added to your .aspx or .ascx file, you had to manually instantiate the object in the code-behind. Now, those days are over and Visual Studio auto-generates the code for the objects that represent the controls that you so easily drop on to your pages.
Figure 4 - Adding our designer file
Step 6 - Make our .ascx file an embedded resource so that our designer file can read its contents
Figure 5 - Making our .ascx file an embedded resource
Step 7 - Using the Page's ParseControl method to read the stream of data that represents our .ascx content string to instantiate our object
public partial class UserRepeaterControl : WebControl
protected override void CreateChildControls()
Container = Page.ParseControl(
rptUsers = (Repeater)Container.FindControl("rptUsers");
private string GetStreamString(string ResourcePath)
using (StreamReader Reader = new StreamReader(
Code 2 - Using ParseControl to instantiate our object
And our .ascx file wil look like:
<asp:repeater id="rptUsers" runat="server">
<%--Content Goes Here--%>
Now, we are free to use our control in as many websites and web applications that we want. Any change made to this control will automatically propagate everywhere that has the latest reference to the DLL.
Nothing in life is perfect, so here's a few things to watch out for:
Event handlers have to be added in the code-behind.
You have to use the "FindControl" method to find controls inside of your newly created User Control.
You can't have ASP.NET tokens within this control.
Use it and leave me some comments and suggestions. Thank you for reading!