There are times that you have to think outside the box to get your designs to work. I've been working on a set of server controls that handle view/add/edit capabilities on a n-tiered vertical table set. You feed the primary control a Category, point it at DataSets containing the schema and the values, and tell it what natural key to use to select the values to be displayed. As you get deeper into the recursion of the data the sub-controls still need to know what the root control is.
The tree built by the data is displayed by recursively adding new instances of the root control to represent a branch in the tree. Since ASP.Net only knows of about the control that are defined in the ASPX page, it becomes necessary for child controls spawned by the tree need to register their events through the root control.
Even though there are better ways to accomplish this, I decided to add a RootControl parameter which is given a reference to the control defined in the ASPX whenever the tree branches. This works fine when you can place code in the Code-Behind to set this property, but what if you are adding a new root control dynamically, such as in a repeater?
Uh, Oh!
<itemtemplate>
<cc1:control runat="server" rootcontrol="???" />
</itemtemplate>
Secret 1, the target objectASP.Net takes ASPX code, which is a loose form of XML, and generates C# (or VB.Net, or some other language) from the tags defind as above. Inside this code, ASP.Net creates a new method to render each control, and inside this method the control is instantiated with the name target.
The next part of the secret is that the DataBinding context actually inserts code as an expression directly into the code of this new method. This is the little bit we need to create a self-referencing ASPX tag.
Oooh, that's cool!<itemtemplate>
<cc1:control runat="server" rootcontrol="" />
</itemtemplate>
ASP.Net can now create the self reference that the control structure requires to render the tree!
Secret 2, ASPX as C#There's a lot of really good info that can be discerned about how ASP.Net works when you look at the source code created when your ASPX page is parsed. You can see this code by opening the Windows Explorer and navigating to "X:\Windows\Microsoft.Net\Framework\v1.0.3075\Temporary ASP.Net Files". You may find this directory in a slightly different location depending on the version of Windows and version of the .Net Framework installed.
Once you're there, you'll find a directory for each ASP.Net application on your webserver. Just start browsing through this directory structure and you'll run across a ton of C# (or VB.Net or J#) source code files with 8-character gibberish for filenames. These are the source files created when ASP.Net converts a page from ASPX to source code, and these files will give you tons of insight into what's going on under the hood with ASP.Net.
Secret 3, ASP.Net and the GACHere's another little dilemna you can find yourself in; occasionally when doing development of shared assemblies you run across a situation where you replace the shared assembly in the GAC, but an ASPX page uses a object that is drastically changed in the shared assembly. ASP.Net only recompiles the ASPX page when it changes, which leaves you with a broken reference to the old shared assembly. You can easily recompile your code-behind to use the new version of the shared assembly, but short of touching each ASPX page and resaving them, ASP.Net seems to resist all attempts to bind to the new shared assembly.
The fix is actually very easy. Simply locate the ASP.Net application's directory in the Temporary ASP.Net Files directory, delete it, then revisit the page on the website. Oila! ASP.Net will recompile all your ASPX pages, and they'll have correct references to the new shared assembly!
