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
- Event Handling
The start of the application is not associated with any event, rather just to indicate the request has been passed onto the page.
Entry point of the ASP.NET page life cycle.
Event fires after all the controls on the page have been initialized and skin configuration applied.
Event fires when all of the page and control initializations complete.
Event fires once everything is loaded and has been set to its previous state.
Event fired once the page is completely loaded.
The final step in the load cycle.
Event is fired once the PreRender is complete.
Triggered when view and control states have been saved.
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”/>
<!—This will affect non-aspx pages — >
<remove statusCode=”404” subStatusCode=”-1”/>
<error statusCode=”404” path=”/error.aspx?type=404” responseMode=”ExecuteURL”/>
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!