My understanding is that when a component or custom control is defined in an aspx page using the <%Register%> tag, it is declared in an auto-generated designer.cs (C#) file by the compiler. If this custom control is never used in the aspx page, does this still happen in the designer.cs file?
Assuming the control is used in the aspx page, what mechanism then instantiates this control, how is it new-ed up behind the scenes? The designer file only declares it. Thanks much, and if there are good articles out there discussing this I’d be happy to read them.
This may not answer all your questions, but some of them. Rick Strahl wrote a great article a while back on compilation and deployment that describes how it works:
Compilation and Deployment in ASP.NET 2.0
I added part of the article that I think relates most to your question below:
Referencing other Pages and Controls
Remember that page and control compilation happens on a per directory basis! So referencing other pages and controls becomes a little more tricky for ASP.NET 2.0, because you can no longer assume that a CodeBeside class from another page or control is available in the current assembly. At best all pages and controls in the same directory end up in the same assembly, at worst each page or control gets its own assembly and they know nothing about each other.
If you need to reference another page from a control or another page you need to explicitly import it with the #Reference directive. Again this is different than ASP.NET 1.1 where all CodeBehind classes were immediately available to your entire Web application. In ASP.NET 2.0 an explicit assembly reference is required to load it.
Assume for a minute that you have the DataEntry.aspx page I showed earlier and you want to create a second page that uses the same CodeBeside class so you can reuse the page logic, but change the page layout in DataEntry2.aspx by changing a few colors and moving around the controls of the page. In essence you want to have two ASPX pages reference the same CodeBeside file.
Here’s how to do this:
<%# Reference Page="~/DataEntry.aspx" %>
<%# Page Language="C#" AutoEventWireup="true" Inherits="DataEntry" %>
I’m leaving out the CodeFile attribute reference the CodeBeside class of the DataEntry page, and add the #Reference tag to the page to force the CodeBeside class to be imported.
The same is true with any User Control definitions. To import a user control you need to use the #Register tag, which imports the assembly that the control lives in. ASP.NET is smart during compilation and figures out exactly where related assemblies live based on how the project is compiled. If the control or page lives in the same assembly no reference is actually added. But if it is external – in another directory for example, then the assembly reference is added.
Referencing problems
If you can explicitly reference other pages and controls in your markup pages, then all works well and as expected. But if you dynamically load controls or reference pages dynamically in your code, things get a lot more complicated.
The most common problem I run into is dynamic loading of controls. In ASP.NET 1.x you might have run code like this for dynamically loading controls into a page:
public partial class DynamicControlLoading : System.Web.UI.Page
{
protected CustomUserControl MessageDisplay = null;
protected void Page_Load(object sender, EventArgs e)
{
MessageDisplay = this.LoadControl( "~/UserControls/CustomUserControl.ascx") as CustomUserControl;
this.Controls.Add(MessageDisplay);
}
protected void btnSay_Click(object sender, EventArgs e)
{
this.MessageDisplay.ShowMessage(this.txtMessage.Text);
}
}
CustomUserControl in this case is a simple User Control that lives in another directory and is loaded dynamically at runtime. Further assume that you truly dynamically want to load this control so you may have a choice of several controls, or the end-user might even create a custom control that gets dropped into place instead.
If you run the code above in ASP.NET 2.0 it will likely fail. I say likely because there are some inconsistencies that will sometimes pick up control references automatically, for example if the user control lives in the same directory and gets compiled into the same assembly as the page, or if another page has the control referenced.
It should and usually will fail. Why? Because ASP.NET compiles on a directory level and the CustomUserControl lives in a separate directory and so goes into a separate assembly. It’s not visible to page class to get a strongly typed reference. Intellisense will show a big, fat and red exclamation point or nothing at all for the MessageDisplay control. When you run the page it will bomb.
You can reference the control as the Control type of course, but if you need to access any custom properties on the user control beyond Control properties you can’t unless you resort to Reflection. As far as I know there’s no way to add a reference to another user control or page programmatically because the reference needs to be available way earlier at compile time before your code ever runs.
Alternatives are to not load controls dynamically or at least provide some mechanism to load up any user controls beforehand on a page with the appropriate #Register tags. But that’s not always possible. The other option is to create a user control base class in APP_CODE and expose the public interface there. The main problem with this is that this base class will not have access to any internal controls of the user control and so the base class would have to use FindControl to reference any embedded controls. So this is inefficient as hell, and cumbersome to boot.
I’ve run into similar situations with inheritance scenarios. For example, inheriting one master page off another’s CodeBeside class. All works well, but the ASP.NET compiler complains that the Profile object is being overridden illegally (a compiler warning). Running with the inherited master page works, but there are quirks. User Controls added to the master page often fail with type conflicts as ASP.NET treats the user control added to the base page as a different type than the user control added to the second page.
It’s inconsistencies like these that deal with referencing other types that have made me waste an incredible amount of time, thinking I had something fixed only to find out later that it didn’t actually work consistently when I changed a completely different page. Worse you have to really understand the model to get your head around what might be wrong.
Bottom line: The overall ASP.NET 2.0 compilation model is internally complex. Most of the time you don’t need to understand it, but when you run into these boundary scenarios, you really DO have to understand what goes on behind the scenes to be able to work around the quirks.
Related
I've created a set of user controls in vb.net and in their original project they work fine.
I've since created a user control library dll and I wish to use it in a new project.
I add the reference to the dll fine, specify the tag library in an asp.net page fine and define controls on the page fine.
Everything seems to work except I get no rendered output.
Various properies of the controls and the page_load methods are all called.
Asp.net trace shows the controls in the page hierarchy etc
Just no output where the controls should be - any suggestions?
Update 1
I just compared a trace of the working output compared to the non working.
The working output contains the user controls (and all elements in them)
The non working output only lists the user controls - no content
It therefore seems that the content of the controls is missing somehow - as if the markup is not being compiled with the codebehind, only the codebehind seems to be working.
Update 2
The controls are inheriting from UserControl not control.
You are correct in your summarization in Update 1- your markup has not been included!
You need to provide a bit of elbow grease if your trying to distribute .ascx controls in a .dll but not too much thankfully.
The two main things you need to do:
Embedded your .ascx controls. The .ascx controls need to be marked as an embedded resource in your .dll (as oppossed to 'content')
Create a VirtualPathProvider. This will allow you to load the ascx files directly from the dll they are embedded in.
Unfortunately explaining step 2 is slightly lengthy, however this excellent article helped me out in doing exactly what you want to do.
The beauty of distributing .ascx controls like this is that you dont have to tear your hair out writing custom controls (rendering anything over than very simple html is a nightmare to make sense of).
I assume that you are not confusing between user control (.ascx) and custom controls. For user controls to work, one needs both ascx (mark-up file) along with corresponding code-behind class. User control are typically consists of constituent child controls whose hierarchy is specified within ascx file that provides some UI. In a class library (dll) project, you cannot package ascx files - all you get is the code-behind class. Without ascx, the code-behind class will not have any child controls and hence will render empty. In short, you cannot package user controls (ascx) in a class library - you have to add them into your actual web project.
For shared control, one has to use custom controls. Custom controls are code-only and typically provides render override that emits necessary html (or creates the own child control tree dynamically). These controls can be package as a class library and shared across project. Typically, a custom control will also have other helper classes to provide design time assistance (UI Editors etc).
I have a Master Page which controls the styling of my site. In the Code Behind, there are a few class instances instantiated as well as variables. These classes validate user access and then create user objects
I have a few Web Content Forms which carries out instructions based on the user objects. So far it seems that on each Web Content Form I have to create new instances of the classes found on the Master Page. This is doubling my work for every Web Content Form.
Is there anyway I can inhereit Classes and objects instantiated in the Master Page Code Behind?
Expose the objects (and even controls) as public properties (get only for controls) on the Master page. Then, in each aspx page you want access to these objects, add the following declaration at the top:
<%# MasterType VirtualPath="~/MyMasterPage.master" %>
As #Kristof points out, simply access your properties like Master.PropertyName
Also, you can determine if it makes sense to store the objects in the users Session (don't forget that they must be serializable if you use DB for session state). I do this often and control access to them via properties in a base Page class that all my pages inherit from. Actually, I have a base master, page, and usercontrol so I have access to the same properties (for me it's CurrentUser) everywhere.
I believe you can if you make the properties public.
Then in your child-page you can make the call something like this:
SiteMaster master = (SiteMaster)this.Master;
master.MyProperty = 0;
Where SiteMaster is the class for your master page. (SiteMaster is the default for the app templates)
Though my mind can deceive me, I haven't done it for a while...
A supposedly proven technique to turn UserControls of a website into reusable server controls while retaining the ability to use declarative code gives me a NullReferenceException on any reference of any control that's declared inside the ASCX code.
When calling the ASCX from the same project, this problem does not occur.
The idea is that the on-demand compilation of the declarative code of the controls is done (precompiled website). After applying aspnet_merge, the awkwardly named assemblies receive normal names, however, if this first step isn't working... What I did, in short:
Create a website, add a usercontrol, add a Literal and set its text in the code-behind. Test it.
Compile to fixed named assembly, non-updatable
Take the output DLL, add them to another webite project and test them.
The last step gives me the null reference exception the minute I try to access any property of a declaratively initialized control from within that control (i.e., in the Page_Load in my case).
PS: Scott Guthrie explains the same technique here.
I've created a UserControl with the following public property:
[Browsable(true)]
public string Text
{
get { return pnlLookupTable.GroupingText; }
set { pnlLookupTable.GroupingText = value; }
}
pnlLookupTable is, as you may have guessed, a Panel control. I can change the value of the Text property in the Properties window and it's reflected in the markup like it should be. However, the design view of the UserControl inside a page does not show updated GroupingText for the Panel. How can I get this to happen?
EDIT:
By request, here is the entire class to which that property belongs. You can see there's nothing special going on:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class LookupTable : System.Web.UI.UserControl
{
[Browsable(true)]
public string Text
{
get { return pnlLookupTable.GroupingText; }
set { pnlLookupTable.GroupingText = value; }
}
}
And here's the relevant part of the .ascx file:
<%# Control Language="C#" AutoEventWireup="true" CodeFile="LookupTable.ascx.cs" Inherits="LookupTable" %>
<asp:Panel ID="pnlLookupTable" runat="server" GroupingText="Lookup Table">
<%-- Irrelevant content here. --%>
</asp:Panel>
I have changed some identifiers and other trivial things to protect the proprietary nature of the code.
I should also reiterate that I'm looking at a Web form in design mode that has my control added, and I'm changing the Text property. I want to see the change to the Panel's GroupingText visually in the designer.
I'd have to think back a bit to the UserControlDesigner code...
Short story: I don't think it's possible.
And here's the long story:
From what I recall, User Controls located in ASCX files are never run in the designer. That is, the code inside the ASCX or ASCX.CS file is never compiled or run in Visual Studio. This is to prevent memory leaks caused by the fact that in the CLR you cannot unload assemblies that you have loaded. In order to run the code in your User Control, Visual Studio would have to compile your ASCX into a DLL, then load it, and then run the code. Every time you make a change to the ASCX, it would have to perform this operation again. Every time this operation happens more memory will be consumed by the additionally loaded DLL generated from your ASCX.
Because of this limitation in the CLR the User Control designer doesn't actually compile or run the ASCX file. Instead, it parses the ASCX file and looks for controls inside it and it loads those controls instead. For each control it finds in the ASCX file it will create the associated control designer and render that control's design time HTML.
There are a couple of ways to work around this:
Instead of using an ASCX user control you can write a regular custom control that derives from Control and the code is written in a CS or VB file.
Compile the ASCX into a DLL. David Ebbo wrote a blog post on how to do this.
The reason that these two solutions should work is that they both involve having the code compiled into a DLL. The idea is that the DLL doesn't change very often so it is safe for Visual Studio to load the DLL without risk of having to reload it for each time the DLL changes (and leak memory).
I thought for sure I had an answer for this, and wrote it all out, but something was bugging me about it so I ended up testing this out for a few hours.
Turns out that (just like Eilon said), I don't think you can do this.
ASCX controls completely ignore the DesignerAttribute, so you can't specify a custom design time renderer for them. I thought "fine, I can subclass the Panel control and specify a new designer on it that will get properties from the parent control". Guess what? No chance. If you access the Panel's parent control in the designer, it will not cast to the custom usercontrol type. I can see that it's a UserControl, and it can't possibly be any other UserControl except my TestUserControl, but the designer class throws an exception if I try to cast it!
This blows my mind to be honest. It's basically exactly what Eilon is saying - there is an intentional restriction on web usercontrols in design mode.
Here's a vague post from Steven Cheng suggesting that design time support is just a no-go for web usercontrols.
While this was a fun learning opportunity for me, I'm sorry to report that I don't think an .ascx will cut it. I'm pretty sure that even compiling it to a DLL like Eilon suggested won't even do it. You'll probably have to go the custom control route.
I'm working on a project that has all its user controls registered in its web.config file (which seems very clean and tidy)
So far so good (here comes the problem) however I'm trying to dynamically create and add user controls to a page. These user controls fire events that need handling.
Ordinarily that wouldn't be a problem:
You just register the control in the page, load the control, cast it to the correct type, and assign the event handlers, add it to the page, sit back and let the magic happen, easy peasy.
But I can't reference the control's type when the control is registered in the web.config, which means no cast, which means no event handling!
Weirdly you can reference the type if you add the usercontrol to the page at design time!
There must be a way round this (without having to register the control on the page, or add a control at design time), what on earth am I missing?
It's been a while, but I think I've seen this type of behavior in ASP.NET when a project is a Web Site and not the Web Application. As far as I remember, the Web Site compiles each page into its own assembly and with no common name space and regardless of config requires the <%# Register %> directive. If you don't, you get the exact error of missing an assembly reference.
I would have to test to be sure...
By saying : "you can reference the type if you add the usercontrol to the page at design time"
Do you mean it adds an <%# Register %> Directive at the top of the page ?
Or maybe, it adds a using / Imports (depending on you using c# / vb.net) clause in your source document ?
Because, to be able to cast to your control type, you normally need to import the namespace in the codebind. Maybe this is just what is missing.
The <controls> section in web.config and the <%# Register %> directive are the same thing (with the small exception that entries in web.config apply to the whole application). They allow you to add design-time controls to a web form.
If you want to add controls to a page dynamically, use the LoadControl function to get an instance of your control. Given a control with a class name of "Header", the following will load a control, set a property, and add the control to the form named, "form1":
Dim head As Header = LoadControl("~/Controls/Header.ascx")
head.Text = "Some text..."
Me.form1.Controls.Add(head)