Server Side ViewState

Server Side ViewState: I will have a closer look at this later

Documenting Exceptional Developers

Documenting Exceptional Developers seemed gives some pragamatic arguements on use try-catch wisely.

If Matt insists to make 'user login failure' kind of things as exceptions, I will show him this article and call him 'exceptional coder' ;-)

Also from Peter Bromberg, Build a Really Useful ASP.NET Exception Engine is more interesting to try out.

OnError and [Page]_Error

Aspx Page have two event methods: [Page]_Error and OnError. They are different. OnError hands control to a private HandleError method. HandleError checks whether web.config:customErrors is turned on and redirects request accordingly.
The base implementation on OnError: checks whether tracing is turned on and adds its own bit about the exception just raised. The main reason to override OnError is to replace this behavior with your own implementation. There is no good reason to put other code there. If <customErrors> turned on, code in OnError will fire first then redirect request to customized error page. In this case code in Page_Error will not fire, as OnError fires first.
To do error-handling at the Page level, use Page_Error.

Experiment
Create an aspx page ManMadeError with both event handling methods:

private void ManMadeError_Error(object sender, System.EventArgs e)
{
Exception ex = Server.GetLastError();
// System.Diagnostics.Trace.WriteLine(ex.ToString(), "Error");
if (Trace.IsEnabled)
Response.Write("Trace on");

Trace.Warn("Error",ex.ToString());
Session["Error"] = ex;
Server.ClearError();
Server.Transfer("500.aspx");
}
protected override void OnError(EventArgs e)
{
Response.Write("<h1> We have a problem </H1>");
}

in Web.config, we have

<customErrors mode="On" defaultRedirect="./Errors/500.aspx" >
<error statusCode="401" redirect="./Chp8Security/Authen_2.aspx" />
<error statusCode="500" redirect="./Errors/500.aspx" />
<error statusCode="404" redirect="./Errors/404.aspx" />
</customErrors>

Fires the exception, and watch the implantation in ManMadeError_Error is ignored entirely.

Customised application error page

We can specify error pages to intercept HTTP errors using Web.config file.
To display a specific error handling page for HTTP status code such like 404(NotFound), 500(InternalServerError), 401(Unauthorized)etc we can add the following element to the web app’s web.config file:

<customErrors mode="On" defaultRedirect="./Errors/wehaveaproblem.aspx" >
<error statusCode="401" redirect="login.aspx" />
<error statusCode="500" redirect="./Errors/wehaveaproblem.aspx " />
<!-- redirect to the 404 page only valid for URLs that end with aspx.
Need to config IIS to take other page types -->
<error statusCode="404" redirect="./Errors/404.aspx" />
</customErrors>

To the 404 error, by default it only works for .aspx and .asp pages. Requesting pages like .htm or .html will still fail back to default MS 404 page. To enable our IIS App handling .htm, you need to map .htm/.html request so it could be handled by aspnet_isapi.dll.
Open IIS manager, click ‘(Application) configuration…’ and in ‘(‘Application mapping’ tab, add htm extension. Map it to ‘((install_drive) \WINNT\Microsoft.NET\Framework\(version)\aspnet_isapi.dll.

Once this is done, you may notice the app is giving back a 500 at default home page (http://www.mySite.com/), if you use a default.aspx page. This is because the default document retrieval order is set to default.htm-default.asp-iistart.asp-default.aspx. Add a dummy default.htm page to redirect the request to default.aspx as following(need client side to enable scripting):

<script language=javascript>
window.navigate("default.aspx")
</script>

The other way to do display customised error page is by configuring IIS in Custom Errors Setting.

ASMX serialization vs. binary serialization with remoting

Remoting is useful for crossing app domains, but not for crossing machine boundaries. Check
this

IsAuthenticated?

Issue: Form Based authentication, authenticated state cannot be kept between pages navigation in a web application.
The sample web app has been tested on a w2k svr which is a domain member and worked fine.
Moving to a stand alone w2k- my home PC, it failed. Trace file indicates the credentials has been authenticated (FormsAuthentication.Authenticate). On page redirection (FormsAuthentication.RedirectFromLoginPage(txtUserName.Text, false);), the authenticated state lost.
Having run the IIS authentication diagnostic tool (http://www.iisfaq.net/), I found it point to the fact the IIS Web Server needs to be a domain member.