Archive | Configuring and Deploying Web Applications RSS for this section

Application Pools

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.

Read More…

Configure Projects, Solutions and Reference Assemblies

Configure Projects

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.
Read More…

ASP.NET Application Compilation

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.

Read More…

Publishing Web Sites

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.

Read More…

ASP.NET Web Site Types

There are four types of ASP.NET websites:

  • Local IIS site:
  • Benefits: testability in IIS environment, site is accessible from other computers
  • Disadvantages:  demands administrative rights, can be debugged only by one user
  • File-system based site:
    • 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
  • FTP site:
    • 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.
  • Remote site:
    • Pros: testability, access for multiple developers
    • Cons: debugging issues.

    Read More…

    Configuring Session State

    Session State:

    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.

    Read More…

    ASP.NET Authorization

    ASP.NET Authentication/Authorization

    ASP.NET Authorization:

    There are two main authorization types: File Authorization and URL Authorization. Let’s start with the latter:

    URL Authorization:

    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.
    Read More…

    Forms Authentication

     ASP.NET Authentication/Authorization

    There are four types of authentication in ASP.NET:

    • Windows authentication
    • Forms authentication (used by the membership API)
    • Passport authentication (mostly obsolete, consider Windows Live instead)
    • Anonymous access

    Forms Authentication:

    Forms Authentication is a token-based auth method. After login, the user gets an encrypted cookie with the login information. This token can also be stored in the query string, but more of it later. The process is simple:

    1. The client makes a request.
    2. IIS (if configured properly for Forms Authentication) passes the request to ASP.NET.
    3. ASP.NET checks for an authentication cookie (or info). If found it, proceeds to step 7.
    4. Redirects the user to the login page (default Login.aspx in machine.config).
    5. User enters credentials, ASP.NET authenticated. If authentication fails, access will be denied.
    6. If authentication succeeds, a cookie will be attached.
    7. ASP.NET tests the authorization settings and the current user.
    8. If fails, access will be denied, else access granted.

    Pros to use Forms Authentication:

    • Full control over the authentication code, via Membership API.
  • Full control over the appearance.
  • No browser-incompatibility issues.
  • Enables to decide where and how to store user information.
  • Read More…

    Windows Authentication

    Hello, as I promised, here is a brief note about Windows Authentication in ASP.NET. I omitted the too advanced tools, which won’t be needed for this exam.

    ASP.NET Authentication/Authorization

    There are four types of authentication in ASP.NET:

    –          Windows authentication

    –          Forms authentication (used by the membership API)

    –          Passport authentication (mostly obsolete, consider Windows Live instead)

    –          Anonymous access

    Windows authentication:

    Use it when:

    –          Dealing with a smaller set of known users.

    –          Who have Windows user accounts.

    –          Potentially in intranet applications.

    Windows authentication matches web users to the predefined Windows users (local or Active Directory). WA isn’t a built in feature of ASP.NET, IIS handles everything. To configure it, set authentication mode to Windows in the web.config.

    Read More…