One thing i've always wondered is why there's no obvious possibility of developing reusable web user control libraries within Visual Studio .NET. There is the “web control library” project template, which is supposed to contain web customcontrols, but there is no straightforward way of adding web user controls to that library. Maybe a lot of folks like developing web custom controls libraries, but for me the custom (or lately composite) controls don't quite cut it. I mean, let's face it, for a composite control (that is a control whose sole purpose in life is to bind together other existing controls) would you rather code your control's layout or design it in markup? The answer's obvious (if you're not a masochist) and the balance clearly leans towards user controls, since they provide a clear “Page-like” separation between markup and code. But enough rambling, here's the deal: although, as I said, there is no straightforward way of reusing user controls across applications, it turns out there are at least three ways to do it (that are not so straightforward :)):

1. As explained by Scott Guthrie here and here, you could basically build a reusable user control library as a web site. More to the point, you create a web site (or web application) project, add your user controls to it and compile it (meaning that you get one or more assemblies with code and one or more .ascx files representing your controls' markup). Then, in the web site where you want to use the control library (that is, the website containg user controls), you can just add a reference to the previously built assemblies, copy the .ascx files in your website and start dropping them on the pages of your choice. The solution is pretty ok as far as I'm concerned, the only thing about it that I don't like is that it doesn't feel “natural”. I mean, after all, you do use a website (or application) as a control library. While there might not be any implications to this (although there are, one that comes to mind is the inability to have any helper code in the user control website/library in asp.net 2.0, because it would have to reside in the App_Code folder and then, since there are no namespaces in the asp.net 2.0 web sites, it might collide with the App_Code of the web site it's being used in) I'm still not quite at peace with this kind of deployment.

2. As explained in this excellent article on codeproject, you could basically build a custom control library, add a custom control to it and, for that control, also add a .ascx file by hand and set its build action to embedded resource. Then, the custom control would load the markup from the resources at runtime, do a ParseControl on it to create a control and then add the newly created control to its (the custom control's) control collection. This solution is also pretty good, the only nasty thing is that, since the custom control is nothing more than a placeholder for the user control that gets created from the markup at runtime, the custom control must assign the correct references (from the newly Parsed control from markup) to any child controls declared in it it wants to have. For complex controls this can be a drag and although it could be automated, it would be time consuming. On the bright side, from the client's point of view, your control is very easy to use. No need to copy .ascx files anywhere, just reference the library and you're good to go.

3. Basically a mix of the above, it goes like this: create a class library project. Add both a code file and a .ascx file (for the markup; you will have to add the .ascx file by hand, maybe by generating it/copying it from outside visual studio in the project's folder and then including it in the project). Because I have a short memory I usually start by copying the contents of a clean user control that VS.NET generates when you add one to a regular web site. Let your control derive from UserControl (not as in 2, from Control or CompositeControl). Build your control to your liking, you even have designer support (in VS.NET 2005 at least, haven't tested in 2003). Now build the class library, you should get an assembly plus a number of .ascx files containing the markup. Reuse them in the same fashion described at 1. You have to be careful to delete the CodeFile attribute of the @Control directive or you will get a "file not found" error when building the web site using the control (since the .cs code file is already built into the reusable assembly). Also, when loading the control dinamically, through Page.LoadControl (note that you can also drag-and-drop the ascx file into the page in the designer and there's nothing else you must do) be careful to add it to a runat="server" control, such as a Placeholder, or you will get a runtime error. To wrap up, what I like about this solution is that it kinda gives me the best of both worlds (1 & 2), without incurring the "overhead" and problems of reusing an entire web site/application (as 1) and without the need to resort to mapping controls and embedding resources (as 2), while still being able to contain other code that it might need (unlike 1).

So there you have it, three ways I know of to reuse web user controls. I'd be happy to learn more if you have any ideas and, of course, any feedback on the above is greatly appreciated.

You are right, it is *almost* identical. The reason why i wouldn't go with a web application project for a control library is the same as why I wouldn't go with 1, namely that, well... it is a web Application project. I for one don't understand why there isn't a Web Control Library project template to which you can add (using VS.NET) user controls. Because, as stated at 3), you CAN add them by hand. Anyway, as I said above, while the implications of using a Web Application only as a container of Web Controls might be minimal, I still don't like the idea of them being there at all, it just feels "unnatural" to me.

Regarding the adding of classes to Web Application Projects you are again right. And definately, if you don't mind "shipping" an entire web application as a library of web controls it's clearly a better option than choosing a Web Site project.

I am attempting to build a User control Library using your option #3. The controls will be dynamically loaded in my website through a class file in the APP_Code folder using LoadControls. So far, I have created a Class Library project and added my ascx and code behind files. I set each ascx files to &amp;quot;Embedded Resource:. I removed the CodeFile attribute from each ascx file. When I compile, I am getting errors stating the controls in the ascx file cannot be referenced in the code behind file. How did you resolve this issue?

Maybe I wasn't clear enough when explaining option #3. It involves the following steps:

1. Create a regular class library.2. Add "by hand" .ascx and .cs code-behind files to it.3. Compile.4. Reference in another project the .dll obtained at step 3, then COPY all .ascx files to the project you want to use the controls in. For all .ascx files, in the project you copied them to, remove the CodeFile attribute, since the code is now in the referenced assembly.

What you did was basically option #2, since you compiled your .ascx files as embedded resources in the library. As outlined above, with option #3 you have to manually copy and include the .ascx files in the project you want to use them in, plus reference the .dll containing the classes with the code-behind (or beside) for them.

Hi, Great article thanks.One further issue I faced is dealing with my own controls that are registered for use with their own prefix. For example:

<mylibrary:MyControl runat="server" ID="myControl" />

In my website I am using the web.config method to register these controls, rather than registering them on every page using directives. For large, complex websites I think this way is far superior.

The problem is that all my websites have to use the same prefix or else I get runtime errors. If I don't use the same prefix with every project then I have to go through and rename all the prefixes every time I import the user control library.

OK, it's not the worst problem in the world but it's a step away from being a really elegant drop-in user-control library.

What I have in mind is not an option, but rather a method to enhance re-usability. You could try implementing design patterns such as Model-View-Controller (MVC) and Inheritance. For a better reference, please go here and here. These design patterns can be easily applied to .cs code-behind files.