Avoiding @Register, cannot instantiate controls registered in web.config (2.0)

[richard.tallent]

I'm fond of web controls in ASP.NET, but the need for <@ Register%>
blocks at the top of each page is a pain.

ASP.NET 2.0 has a way to centrally register controls in the web.config
file, but it is poorly documented and appears to be broken.

I have added my standard user controls to my web.config file. The MSDN
examples are flat wrong, by the way (bad XML case and attribute names,
won't compile). The proper syntax for registering server and user
controls is as follows:

<configuration><system.web><pages><controls>
<add tagPrefix="RST" namespace="RST.UI" assembly="RST.UI" />
<add tagPrefix="RST" tagName="Header"
src="~/controls/header.ascx" />
</controls></pages></system.web></configuration>

Ok, so now I can use declarative instantiation on any ASPX page,
without the need for a page-level @Register directive:

<RST:Header runat="server" id="MyHeader" />

And, with at least one instance of a particular control created that
way, I can programmatically create others:

Public Sub Page_Load()
' ClassName="Header" in the header.ascx
Dim o As New ASP.Header
End Sub

The problem is, I am usually creating *every* instance of some controls
dynamically in the Page_Load() method. But without at least one
declarative instance or an @Register directive, I get the following
error:

Type 'ASP.MyHeader' is not defined.

What am I missing here? Creating dummy instances of every control class
is even worse than having an army of @Register directives on every page.

 

[Nathan Sokalski]

I will admit that I have not tried using web.config in place of the
@register directive, but in your example you have an attribute of

assembly="RST.UI"

I could be wrong, but aren't assemblies usually .dll files? I think that
there might be a way to add a line in the AssemblyInfo.vb (or whatever file)
file that does what you want. Try looking into that, although I won't make
any promises since I prefer the simple @register technique, I don't think
it's that bad when all you have to do is a little copy & pasting. Good Luck!

 

[richard.tallent]

The assembly name is "RST.UI.dll", and the register directive leaves
off the DLL. But this issue applies both to DLL and ASCX controls.

Copy and paste is never a good programming practice. I make heavy use
of custom controls, so centralization is a key requirement, and I don't
want to give up using ASCX files in the process.

 

[Nathan Sokalski]

Did you try looking into a way of adding something to the AssemblyInfo.dll
file that accomplishes what you want? I'm not sure exactly what it would be,
but I seem to remember reading something about a way to use AssemblyInfo.dll
that might accomplish what you want.

 

[richard.tallent]

Nathan, thanks, but I think you are missing the point. ASCX files don't
*have* an AssemblyInfo.dll file, they are standalone, plain-text files
that are compiled dynamically by ASP.NET.

ASP.NET is supposed to offer this functionality now via the web.config
file, but it appears to not work as advertised, and the SDK
documentation is completely useless.

 

[Nathan Sokalski]

I apologize, I meant to say the AssemblyInfo.vb file. This is a file
required by all ASP.NET applications written in VB.NET (if you are using C#
it is called AssemblyInfo.cs). Like I have mentioned before, I have never
modified this file, so I don't know everything that can be put in it or what
it can be used for, I am simply suggesting that you look into it.

 

[Warazen]

Try the @Reference directive.

I had a similar problem yesterday on a web form that registers 12 user controls. Upon compiling, Visual Studio 2005 would show "Build Succeeded". However, the Error List would display:
Type 'ASP.common_wuc_wocontact_ascx' is not defined.
Type 'ASP.common_wuc_wodestination_ascx' is not defined.
etc.

Additionally, the page declaration on the code-ahead, and the Imports statements on the code-behind failed. This was on a project that previously compiled successfully. Several forums recommend restarting Visual Studio, or even rebooting. Those suggestions did not resolve my issue.

What did work, was adding an explicit @Reference directive to one of the controls on the web form, like this:
<%@ Reference Control="~/Common/wuc/Attachment.ascx" %>

According to Microsoft, @Reference "Indicates that another user control, page source file, or arbitrary file located at some virtual path should be dynamically compiled and linked against the current ASP.NET file (Web page, user control, or master page) in which this directive is declared."

So in the end, there were two directives pointing to the user control, which looked like this:
<%@ Reference Control="~/Common/wuc/Attachment.ascx" %>
<%@ Register Src="../Common/wuc/Attachment.ascx" TagName="wucAttachment" TagPrefix="uc8" %>

One other thing of note, now that I'm comparing the two statements, use of the tilde (~) versus the dots (..) in the @Register directive may have impacted this as well. I don't have time to investigate this right now, but someone with a similar problem may decide to experiment.

The above solution was culled from the following links:
http://www.codecomments.com/archive315-2006-2-787512.html
http://msdn2.microsoft.com/en-us/library/w70c655a.aspx

 

[Wilfred Knievel]

Just asked this on stack overflow [I can't post a link but it's question id 643645]

Anyway it appears that if your project is configured as web application this works fine but if it's configured as a web site you'll get the problems described above.