They are all inherited the Interface IHttpHandler,so the asp.net will call they by the same way. But why the aspx page inherited IDispose? Asp.net is how to achieve it?
ASP.NET page is inheriting from the base System.Web.UI.Page class which in turn implements the abstract System.Web.UI.TemplateControl class that inherits from System.Web.UI.Control which implements IDisposable.
In the code, there is the remark for the Dispose() of the Control class:
// Summary:
// Enables a server control to perform final clean up before it is released
// from memory.
That's the reason why .aspx file essentially implements the IDisposable interface.
Now, ASP.NET handler is directly implementing the System.Web.IHttpHandler interface without inheriting any other classes - being independent interface, it does not implement IDisposable - it's up to the programmer to decide whether to add such thing or not.
So your question is, how does the Dispose() code of the aspx (Page) ever get called?
You're making the assumption that ASP.NET framework only sees an IHttpHandler, whether it contains a Page or another implementation. That's almost certainly not true; something needs to call the page's constructor.
You could use a tool like IL Spy to try to find where the different handling is, and what it looks like.
Related
I have created a class in asp.net and I want to inherit the Main Page. I have tried below but it has an error:
Public Class Class1
Inherits Main Page
End Class
In windows Application inheriting form is much easier than in asp.net. Just like below:
Public Class Class1
Inherits FormMain
End Class
Can someone help me on inheriting page in a class?
Thanks in advance.
Your class name must be a single word. Try Main_Page or MainPage since in many cases the underscore character is hidden by other elements or the cursor.
Otherwise, search you project for the class and make sure you are using the same name as the actual implementation of the class.
This is probably not something you want to really do. The web page in ASP.NET WebForms consists of two parts - Design and Code-behind. The design part is translated into rendering Visual Basic code during compilation.
I can't see a reason for deriving from a WebForms page. What are you trying to achieve? You can certainly change the base class the page uses, but there is practically no logical reason to derive from it.
EDIT:
You might be actually trying to do something in the sense of having a base page and then other pages that have the same basic "structure". That is possible, but using a different ASP.NET mechanism called MasterPages (http://msdn.microsoft.com/en-us/library/wtxbf3hh.ASPX)
Assuming your MainPage is your inheriting class, then make sure it's declared something like:
''' <summary>
''' Base page for all other web pages in the system.
''' </summary>
Public Class MainPage
Inherits Page
...
End Class
Your ASP.NET class would then be:
Public Class Class1
Inherits MainPage
...
End Class
When implementing authorization for ASP.NET, where should I put AuthorizeAttribute implemented class?
In my project, I have created a class called BasicHttpAuthorizedAttribute which implements System.Web.Http.AuthorizeAttribute class and I have overridden the methods I want.
I have registered this BasicHttpAuthorizedAttribute class as a filter.
My problem is even though I do not mention the [Authorized] attribute on top of controller method, BasicHttpAuthorizedAttribute class's OnAuthorization() method gets called.
That should not be like that, right? It should only be called if you have mentioned [Authorized] attribute on top of controller method. Am I right?
What am I doing wrong here? (My project is a ASP.Net web api project and I am using System.Web.Http.AuthorizeAttribute class)
Basically, it goes into the OnAuthorization() event each time because you've registered it as a filter.
This article has a few neat tips and trips on blanket filtering and anonymous exceptions, which is, I think, what you want. It may be for MVC, but the techniques used should apply to most ASP.NET types with a little tweaking.
http://blogs.msdn.com/b/rickandy/archive/2011/05/02/securing-your-asp-net-mvc-3-application.aspx
Example from article:
[HttpPost]
[AllowAnonymous]
public ActionResult LogOn(LogOnModel model, string returnUrl)
I want to do some additional processing of the output of all my views before they get sent to the client.
I tried setting the view base class to a custom class where I override Execute, but that doesn't work because Razor will generate its own Execute in the derived class that doesn't call mine.
Is there another MVC-specific way to do it, or my only hope is to resort to the "classic" way of doing it, by setting Response.Filter in Application_BeginRequest in Global.asax?
You should implement IResultFilter. Common way to do it is by deriving from ActionFilterAttribute
void OnResultExecuted(
ResultExecutedContext filterContext
)
I have just moved over to using ASP.NET MVC 2. In web forms, I normally had a BasePage class that extends from System.Web.UI.Page. And then every page extends from this BasePage. In this BasePage class I have methods that I need. How would I do this in an MVC application?
Any samples would be appreciated.
Thanks.
It is a bit different in MVC. The equivallent would be BaseController although this doesn't correlate exactly to a page in the classic ASP.NET sense. For a start, a controleler doesn't have any markup.
Into a base controller you might inject any model classes that are required by all pages and any common behaviours that have to be executed as part of all Action requests. An example might be some custom checks to go into the Controller OnActionExecuting event...
http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onactionexecuting.aspx
protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
//check the filterContext for a certain condition
if (condition) {
//do something else - redirect to a different route or
//render a different view to to the default
filterContext.Result = new RedirectResult(newUrl);
}
//Otherwise, do nothing, the requested Action will execute as normal...
}
IN MVC there is a greater separation of concerns for rendering the UI, so depending on what the code did in your base page will dictate where it goes in MVC.
If your code generated HTML than you will probably be creating custom HTML helpers and reusable partials views (.ascx). If it handled input data than it will go in a model binder class, and you can create a base model binder for common code. If it talked to your services and domain model than it will go in the controller, and again you can use a base controller. Queries to the persistence layer will go in your model, and reusing code here leads to a much larger discussion of your architecture.
We also moved from base Page classes in ASP.NET and found that a combination of a base controller and a base Model (ViewData) class works well.
So ex Page properties eg: CurrentUser are available from the base Controller and also passed to the base ViewData when its initiated so you can use them on the aspx page.
1) I've page class
public partial class MyDelivery : System.Web.UI.Page
2) ASCX is in different subfolder
public partial class MyControls_Hello_Bye : System.Web.UI.UserControl
I am unable to access #1 parent page class from control
This problem annoyed me for quite a while. I don't think my solution is perfect, but it sure helps my junior developers in coding. We have a base user control that all user controls inherit and we (like you) we have a base page class that all pages must inherit (team rule). In the user control is a property called ParentForm which is strongly typed to the specific page type that will contain it (the page baseclass if that is variable or unknown at the time).
During the load event of the page, we manually set the Parentform Property of all user controls (we do this in our master page for all master page level controls as well).
protected Page_Load(object sender, System.EventArgs e)
{
this.myControl.ParentForm = this;
this.myControl2.ParentForm = this;
}
This provides immediate access from any user control back to the page and any of its exposed methods. It also provides a standardized (within our team) method of allowing controls to communicate between themselves through an interface in the ParentForm.
Our standard is to perform this assignment manually. For me this was a personnel consideration to make sure developers are aware of the controls they are adding (not setting the ParentForm will cause null reference exceptions if you attempt to access it obviously). If you wanted to perform this setting automagically, you could use the base class's Page_InitComplete event to cycle through any user controls and set the ParentForm to "this" that way.
Being in a different directory would get visual studio to give them different namespaces by default, causing the parent page class not to visible to the control.
Make sure the namespace declarations of both classes are the same, or import the parent page class namespace to the contorl with the using statement.