Comparing Web Site Projects and Web Application Projects

We got two options Web Site Projects and Web Application Projects to create Web application in VS 2005.We will see what is difference between Web Site Projects and Web Application Projects and when to use them.

Web Application Projects

• Similar to Visual Studio .NET 2003. Only files that are referenced in the project file are part of the project, are displayed in Solution Explorer, and are compiled during a build. Because there is a project file.
  You can subdivide one ASP.NET application into multiple Visual Studio projects.
  You can easily exclude files from the project and from source code-control.
• All code-behind class files and stand-alone class files in the project are compiled into a single assembly, which is placed in the Bin folder. As it is a single assembly, you can specify attributes such as assembly name and version, as well as the location of the output assembly.
• To run and debug pages, you must build the entire Web project. Building the entire Web application project is usually fast, because Visual Studio employs an incremental build model that builds only the files that have changed.
• For Deployment as all class files are compiled into a single assembly, only that assembly needs to be deployed, along with the .aspx and .ascx files and other static content files.

When to Use:

1. When you required to migrate large Visual Studio .NET 2003 applications to VS 2005.
2. To control names of output assemblies.
3. You need stand-alone classes to reference page and user control classes.
4. You need to build a Web application using multiple Web projects.
5. You need to add pre-build and post-build steps during compilation.

Web Site Projects :

• Web site projects use the folder structure to define the contents of the project. There is no project file and all files in the folder are part of the project.
• The Build command compiles Web site projects only to test them. But to run Web site projects, you deploy source files and rely on ASP.NET dynamic compilation to compile pages and classes in the application. The ASP.NET dynamic compilation system has two modes—batch mode (the default) and fixed-names mode. In batch mode, many assemblies (typically one per folder) are produced when precompiling the site. In fixed mode, one assembly is produced for each page or user control in the Web site.
• pages are compiled dynamically and compiled into different assemblies as needed, it is not required that the entire project compile successfully in order to run and debug a page.
• Both .aspx files and code-behind files can be compiled into assemblies using the Publish Website command in Visual Studio. Build command does not create a deployable set of assemblies. The updateable publish option supports compiling only code-behind files while leaving .aspx files unchanged for deployment.

When to Use:

1. When you need single-page code model to code-behind model.
2. Need dynamic compilation and working on pages without building entire site on each page view (that is, save file and then simply refresh the page in the browser).
3. Need to generate one assembly for each page.
4. Want to open and edit any directory as a Web project without creating a project file.

ASP.NET Session State Overview

ASP.NET Session State Overview

• By default, ASP.NET session state is enabled for all ASP.NET applications.
• HTTP is a stateless protocol. This means that a Web server treats each HTTP request for a page as an independent request. The server retains no knowledge of variable values that were used during previous requests. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides a way to persist variable values for the duration of that session.
• Session variables are stored in a SessionStateItemCollection object that is exposed through the HttpContext..::.Session property.
• When you use a session-state mode other than InProc, the session-variable type must be either a primitive .NET type or serializable. This is because the session-variable value is stored in an external data store.
• Cookie Less Session : The SessionID value is stored in a non-expiring session cookie in the browser. However, you can specify that session identifiers should not be stored in a cookie by setting the cookieless attribute to true in the sessionState section of the Web.config file. ASP.NET maintains cookieless session state by automatically inserting a unique session ID into the page's URL.
• To improve the security of your application, you should allow users to log out of your application, at which point the application should call the Abandon method. This reduces the potential for a malicious user to get the unique identifier in the URL and use it to retrieve private user data stored in the session.
• Session Modes : The default behavior is to store session variables in the memory space of the ASP.NET worker process. However, you can also specify that session state should be stored in a separate process, in a SQL Server database, or in a custom data source.
  InProc mode, which stores session state in memory on the Web server. This is the default. It is the only mode that supports the Session_OnEnd event.
  StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
  SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
  Custom mode, which enables you to specify a custom storage provider.
  Off mode, which disables session state.
• If the Global.asax file or Web.config file for an ASP.NET application is modified, the application will be restarted and any values stored in application state or session state will be lost. Be aware that some anti-virus software can update the last-modified date and time of the Global.asax or Web.config file for an application.