Application pools are essentially URLS served by the same (group of) worker process(es). They set up boundaries between applications, which means an application running in an application pool cannot affect one that’s running in another. Also, a failure of an application won’t affect the apps hosted in other application pools. The third benefit of application pools is that you can achieve better performance by using them.
There are some guidelines you should be aware of when designing application pools:
- Create a unique application pool for each web site in a given server.
- Configure a unique user account with the least possible rights for each application pool.
- If you want to run an application with its unique properties, create its own application pool.
Also, you should not add applications that using different versions of the .NET Framework for the same application pool. It may cause errors.
There are four project types for creating a web application in Visual Studio, which you should be familiar with for this exam. Namely: ASP.NET Web Site, Empty Web Site, ASP.NET Web Service, and ASP.NET Web Application. We will cover ASP.NET Web Site, and ASP.NET Web Application.
ASP.NET Web Site:
This project type is file-based, and there is no project file included. So every file- whatever its extension would be- in a given folder is the part of your project. This is the default web site project type in Visual Studio (simply click on the New Web Site button on the menu (represented as an Earth globe).
This template generates a web.config file with some initial entries, and a Default.aspx page with the given code-behind file for you. Also an App_Data folder will be included to help you begin your work. The above mentioned Empty Web Site project is exactly the same as this project type, the difference is that you won’t get any content generated at startup.
In ASP.NET, there are three compilation models, which are useful in different scenarios. The first one is called Classic precompilation, and is used when you work with an ASP.NET Web Application project type. With this method some parts of the page, such as the code-behind class files, referenced assemblies, etc. are precompiled, and other parts, such as the markup logic (.aspx files) are dynamically compiled at runtime. You can only use this type of compilation with the code-behind model.
The second method is called Dynamic compilation. With it, all of the pages, code files, resources, etc. are copied to the server as is, and ASP.NET compiles them to an executable when the first user requests a site. An obvious drawback of this model is that the first requests of the page take more time to fulfill, so users must wait more. A great advantage is that you can always update the files on the server, without the need of stopping and recompiling your application.
Our third method is Site precompilation. Site precompilation allows you to compile your whole site, even the .aspx files into binaries, which could be transferred to the server. There is no performance penalty, but the updates are considerably trickier.
Be aware of that, from the above three, the default model is Dynamic compilation.
There are two ways of publishing websites in ASP.NET with Visual Studio:
- Using the Copy Web Site Tool from Visual Studio
- Using the Publish Web Site Tool from Visual Studio
Copy Web Site Tool:
Consider using the Copy Web Site Tool when you cannot open the remote site as Remote IIS Site, and need more power over it than a simple FTP Web Site. It supports synchronization which makes sure that all files in both sides are up to date.
When using the Copy Web Site Tool, essentially you are working with two web sites at the same time. The source site, which is the site opened in Visual Studio, and the remote site, where you want to copy the content of the source site. With synchronization enabled, you can choose between the versions of the files you want to hold, or discard. It also enables multiple developers to work on the same site in the same time.
The DOS command line tool named XCOPY has the same advantages as the Copy Web Site Tool, and it doesn’t require Visual Studio to be installed on your computer.
There are four types of ASP.NET websites:
File-system based site:
- Benefits: testability in IIS environment, site is accessible from other computers
- Disadvantages: demands administrative rights, can be debugged only by one user
- Benefits: security, no IIS needed, no administrative rights needed, multiple users can debug it at the same time
- Disadvantages: cannot be tested in IIS environment
- Pros: site can be tested on the server where it will be used
- Cons: site exists only in the server; this project type cannot be created, only opened.
- Pros: testability, access for multiple developers
- Cons: debugging issues.
Session State enables you to store information, which is persisted during page changes. It’s stored server-side, and is essentially a collection like ViewState, or Application state. The syntax is straightforward: Session[“Key”] = Value;
Session state is not shared between clients, like application state. Every user has his/her own session ID, which guaranteed (statistically) to be large enough not to be guessed or reverse-engineered.
To access his or her private session information, the user must provide the session ID. It can be stored two ways (just like the authentication information): in a cookie (ASP.NET_SessionId is the name) or in a modified URL, serving clients who don’t support cookies.
Using Session State:
To store a datatable in a user’s session, just type the following:
DataTable dt = new DataTable();
Session[“Cart”] = dt;
Retrieval is quite easy, too:
Dt = Sesion[“dt”] as DataTable;
Session state can be used in every page of your application, but it’s not immortal. Session information can be lost if:
- User closes/restarts browser.
- May be lost when the user requests the same page on a different browser window. The original page will have the session, but the new may not. This behavior depends on the browser.
- Timeout, due to inactivity. By default, it lasts 20 minutes.
- If you call Session.Abandon();
Sessions lost when the hosting application domain is recreated (e.g.: change a configuration file, recompile application). For a workaround for this situation, you can use out-of-process session management.
There are two main authorization types: File Authorization and URL Authorization. Let’s start with the latter:
Specified in web.config files, with a declarative syntax. URL Authorization only interested in the security status of the user, and the URL resource being requested, hence the name. If the page is forbidden for the requesting user, and forms authentication is used, then the user will be prompted to log in, thus redirected to the login page. If windows authentication is active, the user will receive a 401 – access denied page. It can be customized in web.config customErrors tag, if needed.