Understanding Basic ASP.NET Fundamentals
What is ASP.NET, and how does it work?
ASP.NET is a powerful web development suite designed by Microsoft to allow programmers to build dynamic websites, web applications, and web services. It was first released in January 2002, and is the successor to Microsoft Active Server Pages (ASP). The .NET framework runs on the Common Language Runtime (CLR), allowing programmers to write ASP.NET code using any .NET language.
A new request to an ASPX page causes the ASP.NET runtime to compile the code, it then generates a page class that instantiates and populates a tree of server control instances, which represents the ASP.NET page. After the page is compiled (this only happens once each time the application pool is loaded), the runtime runs through the entire list of controls asking each one to render itself, or output the HTML to be viewable on the clients browser.
What are user controls, custom controls, etc?
User controls allow you to create your own custom, reusable control using the same technique you use for creating ASP.NET webpages. The user control works much like an ASP.NET webpage, you can add existing web server controls and markup to a user control, define properties, methods for the control, and embed them in ASP.NET webpages.
Custom controls are compiled to DLL (dynamic linking library) files, to use a custom control in an ASP.NET project, it gets added to your Toolbox task pane inside of Visual Studio. In most cases, ASP.NET custom controls are developed by third party vendors who distribute the DLL with their product.
What is the ASP.NET page life cycle?
The request of an ASP.NET page triggers a sequence of events that starts the page life cycle. The web server parses the file extension for the requested page and sends the request to the page handler class. Once the request is sent to the handler class. The basic idea of the page life cycle is broken down in the following list:
- Client Request
- Start
- Initialize
- Load
- Validate
- Event Handling
- Render
- Unload
The start of the application is not associated with any event, rather just to indicate the request has been passed onto the page.
- PreInit
Entry point of the ASP.NET page life cycle. - Init
Event fires after all the controls on the page have been initialized and skin configuration applied. - PreLoad
Event fires when all of the page and control initializations complete. - Load
Event fires once everything is loaded and has been set to its previous state. - LoadComplete
Event fired once the page is completely loaded. - PreRender
The final step in the load cycle. - PreRenderComplete
Event is fired once the PreRender is complete. - SaveStateComplete
Triggered when view and control states have been saved. - Unload
Event is fired when the HTML for the page is fully rendered.
What is the proper way to handle ASP.NET 404 errors?
By default, configuring ASP.NET errors in the web.config will only affect files that are parsed via ASP.NET. Files such as HTML, PHP, or other types are not parsed via the .NET engine, resulting in the default IIS 404 page. Below are examples for handling the 404 code for both ASP.NET and non ASP.NET files:
<!—This will affect only ASPX pages — >
<customErrors mode=”On” defaultRedirect=”~/error.aspx”>
<error statusCode=”404” redirect=”error.aspx?type=404”/>
</customErrors><!—This will affect non-aspx pages — >
<system.webServer>
<httpErrors errorMode=”custom”>
<remove statusCode=”404” subStatusCode=”-1”/>
<error statusCode=”404” path=”/error.aspx?type=404” responseMode=”ExecuteURL”/></httpErrors>
Have further questions, comments? Post on our forums! http://hms.to/1dqP2NR
Guest Blogger – Thomas Mack
Tom is a Technical Support Analyst and has been with HostMySite for 2 years. He has been working on a game engine project for the past year and teaching himself about game coding. Thomas codes in ASP.NET, C#, HTML5, Java, C/C++, and actively works with DirectX. When Thomas isn’t working on his game, or assisting customers, he can be found offroading in his jeep!
