I'm developing a stand-alone ASP .NET component for dropping in to various sites we create.
Part of the application is a CompositeControl, which needs to load a UserControl.
However, CompositeControl has no LoadControl() method - in stead, I must (as far as I can see?) rely on Page.LoadControl() and this is a problem!
How do I know the path to my control, when the page is not part of the assembly?
The page the CompositeControl is situated on resides outside the assembly I am writing the Page.LoadControl() code in, and thus cannot find my .ascx file.
I've tried LoadControl(type, object[]) but this doesn't load the "code infront" file, which I need.
So - how do I find the Path to some .ascx file inside some included assembly (name known, ofc) for my Page.LoadControl? Or, alternatively, is there some other way to load the control from inside the CompositeControl?
Cheers!
EDIT:
The following provided the solution, although it is slightly hacky. It does work, however:
http://www.cmswire.com/cms/tips-tricks/aspnet-reusing-web-user-controls-and-forms-000915.php
This may be of some help to you : http://blogs.msdn.com/b/davidebb/archive/2005/10/30/487160.aspx
Related
My confusion is not new here or arround the web, yet, i have some questions for which i did not find answers anywhere:
The first question is:
Why is Inherits necessary on CodeFile and not on CodeBehind?
I read: http://msdn.microsoft.com/en-us/library/vstudio/ms178138(v=vs.100).aspx and some more pages, and i understand that CodeFile is for source code and for compilation on the fly while the other is for an assembly. This raised me another question:
Why do everyone say that CodeBehind must be an assembly if i find
File.aspx.cs everywhere including in a test project i have and it
works like a charm? Is this a compiled assembly?
But, as of the first question, and based on the url i supplied, i might understand, why the Inherits is necessary. I assume the compiler must know what is the name of the partial class to compile later. Makes sense. Yet, shouldn't it be necessary on CodeBehind as well? If we are going to merge the partial classes, i suppose i should give the name of the one i want to merge. I even tried adding another partial class to the .cs file and it compiled/ran well.
Am I missing something here?
I also read that CodeBehind is not used anymore and it's CodeFile, the new one.
Any .NET guru to help me?
Thank you all in advance.
UPDATED:
I tried to implement events using no Inherits on CodeBehind. It didn't work. This makes more sense. But, it doesn't complain on compilation, while CodeFile does. Is there any reason for this?
Inherits property carry the class name which written inside the code behind file. you can have multiple classes in same code behind file and inherit in two different .aspx file
CodeBehind file provides the code behind for the aspx page. When you add a new "ASP.NET webpage with CodeBehind", let's call it NewPage.aspx, 2 files are also created, called NewPage.aspx.cs and NewPage.aspx.designer.cs. NewPage.aspx.cs is your CodeBehind file. As Vijay stated, since a (C#) file can have multiple classes (which is different from Java, where a class file can only contain 1 class, and the class name have to be matching the file name), Inherits=[namespace].[class] indicates which class you want to actually use for the web page.
The CodeBehind attribute is for Web application projects. The CodeFile attribute, on the other hand, is for Web site projects.
My problem seemed easy but I really can't find the right solution. How can I access mg controls (textboxes, grid view, etc) that are located in my default.aspx page from my class library. An error (The name 'GridView1' does not exist in the current context) is being thrown. I'm wondering why since I already added the project where the default page is located in the reference of my class library. I also include it in the namespace.
Exercise1 --> project where my default.aspx page is located
ClassLibrary1 --. where I wanted to use the controls
using exercise1; --> included in the namespace.
What else do I miss? thanks!
It seems to me you're working on this backwards, your class library shouldn't have access to the presentation elements, you should be (in your code behind) calling methods from your class library to interact with your gridview. You shouldn't be calling the gridview from the class library.
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.
I seem to be having a lot of trouble with this.
I want to create an ASP.NET control that implements some core logic, and then I want to be able to derive several controls from that, which each implement their own specialized logic.
I started with a User Control, but I couldn't find a way to derive from it. I tried setting the Inherits attribute in the derived control but, no matter what I did, the derived control just didn't seem able to recognize the base control.
So then I tried a custom server side control by using a regular class that inherits from Control. (Note that all my rendering is done from code.) But I can't seem to find any way to get a page to recognize the control. I've tried different syntax in the #Register directive but either it tells me the src attribute is missing or it just can't find the control. (Note that I prefer not to create a separate assembly if I don't have to.) I have no idea what to put as the assembly if the control is from the current assembly.
Can anyone make suggestions on this? Any examples that would work for my configuration, or perhaps a different approach entirely?
Note that I am not currently using page/control code-behind. All my page scripting is stored in the same file as my markup.
In fact, despite various error messages about missing attributes in the #Register directive, I found it works just fine if I reduce the number of attributes in this directive to just tagprefix and namespace.
In my WAP project, every .aspx's code-behind and designer share the same namespace. For example my Main.Master.cs and Main.designer.cs are both in the OurCompany.Web namespace by default.
When I go to another .aspx page and use the following, I get an "Ambiguous reference" error because it can't decide if I'm talking about my code-behind or designer file of that master page
<%# MasterType TypeName="OurCompany.Web.Main" %>
but by default this is the way VS creates .aspx pages so should I really care?
The designer files are all marked as "partial" classes so they don't get compiled into their own types.
My guess is that you really do have 2 classes called "OurCompany.Web.Main". A tool like Reflector would let you browser your DLLs so you could tell for sure.
This just happened to me, your problem is the JIT compilation creating temporary "copies" of your assemblies in a temp directory.
Make sure every namespace/partial class declaration is "tight", check for incorrect class names, wrong namespaces.
The problem "just went away" for me as well. Recreating or cleaning the solution will probably do it. Wish I could be more helpful but going cleaning up the source, both manually and with the right click menu probably helped.
I'm guessing you have a master page and a web form page with the same name on the code behind class. And this will prevent your site from working correctly (if it works at all).
I'd go through my aspx.cs files and looking for the class name main (find should work here). I bet you will find two files with the name. You will have to change one of them to something else. Just make sure you also change the Inherits in the .aspx page and the .designer.cs class name.