How to add a UserControl to another within a C# library?? (Exception: Could not resolve type...)

I have a C# library that gets built and gets placed into my website's bin folder. In my C# library I have a .ascx file and I'm trying to put another .ascx control in there. But I get this error:

Could not resolve type for tag "fb:FormBuilder". Make sure the proper namespace is registered.

This is in the top of my user control that I want to add to others:

<%@ Control Language="C#" Inherits="System.Web.UI.UserControl, ITextControl" %>

In my parent control, I have this:

<%@ Control Language="C#" %>
<%@ Register TagPr开发者_运维知识库efix="fb" TagName="FormBuilder" Src="~/Resources/ControlTemplates/Backend/FormBuilder.ascx" %>
....
<fb:FormBuilder runat="server" id="FormCode"></fb:FormBuilder>

All my files are set as the Build Option as being "Embedded Resource" (.NET 3.5). Any ideas on how to solve this?

---

The declarative syntax of doing this in the actual ascx file itself expects there to be a file at the location you specify in your register declaration. If that file does not exist, then the compiler doesn't know how to resolve the reference.

Generally, if you author controls that are designed for re-use within other web applications, then your should create them as custom server controls; not as user controls. The server control framework and base classes is designed for reuse and packaging. Authoring a server controls takes a tad bit more time and effort initially, but not much and after you do it once or twice it gets fairly easy.

The only other solution I can think of is to make sure your build/compile is dropping the actual ascx files into a fixed location within the consuming web project. That way your consuming pages will have a valid path to use in the register directive and the file can be located by the compiler. You could use code-behind to dynamically load the controls using Page.LoadControl(). The ascx file still needs to exist physically, but using code-behind to add the control to the page allows you to add some intelligence to the process by reading the path from configuration and the like.

---

This might help:

http://west-wind.com/weblog/posts/3016.aspx

In any case, referencing one library from within another is the kind of cross-dependency that I usually try to avoid.