email article printer friendly more resources

Manage Web Sites With ASP.NET
Multiple versions of the .NET Framework don't need to make it difficult to manage Web sites running ASP.NET applications.
by Randy Holloway

September 2003 Issue

The ASP.NET development platform is a proven entity for creating scalable Web-based applications rapidly, but the adoption curve is a challenge for many IT managers and system administrators. Often, software development projects don't include a sufficient plan for the application-deployment phase. Mixing new technology into this equation typically results in unsecured applications that aren't deployed optimally to production systems. Managing such systems can become a daunting task that consumes an inordinate amount of energy, time, and resources from developers and administrators.

With version 1.1 of the .NET Framework moving into production now in many environments, and version 2.0 coming next year, the complexities of managing Web sites running multiple versions of ASP.NET are a concern for many organizations. For this reason, administrators must have a thorough understanding of the ASP.NET architecture, security infrastructure, and deployment requirements. You must also be prepared to manage side-by-side versions of ASP.NET applications on the same servers, and secure, deploy, and manage applications running concurrently on different versions of ASP.NET effectively.

You must understand the basics of the .NET Framework and its architecture to deploy and manage ASP.NET applications successfully. .NET's key concepts are based on the implementation of the Common Language Runtime (CLR), the .NET Framework's engine. It facilitates the execution of all managed application code. The concept of managed code in .NET is simple: Managed code is translated to executable code by the CLR, rather than executing instructions directly with the CPU. Numerous advantages come with the CLR's design, including the automatic handling of plumbing such as memory management and inter- and intraprocess communication. This enables programmers to leverage the runtime environment to handle many of the complexities they dealt with in the development of unmanaged code, which makes them more productive by allowing them to focus on solving problems with their applications rather than focusing on the infrastructure.

All code in .NET belongs to a unit called an assembly. Assemblies contain two important features: code compiled to Intermediate Language (IL), and metadata. IL is a form of assembly code that the CLR can translate efficiently to executable code at run time. This process is called Just-In-Time (JIT) compilation. The executed code is retained in memory until the host process terminates. The metadata generated by the compiler and contained in a .NET assembly describes both the assembly's individual classes and the assembly unit itself.

ASP.NET development projects include both ASPX files and the code-behind classes. These classes contain the code for the application, separating the business logic from the UI, which the ASPX files define. Once ASP.NET projects are compiled, the result includes the original ASPX files and an assembly for the project containing all the code generated by the code-behind classes and other classes used in the project. These files must be deployed with an ASP.NET application.

Most administrators are concerned primarily about application security when they deploy ASP.NET applications. Administrators are typically responsible for ensuring that applications deployed into production environments don't compromise the security of the network or critical data. You, as the administrator, must understand how ASP.NET security works, in order to ensure ASP.NET applications are secure. First, you need an overview of the security process flow with an incoming request to an ASP.NET application (see Figure 1). When a client requests an ASPX page from an Internet Information Services (IIS) server, the client's credentials are passed to IIS. IIS authenticates the client, then forwards the authentication token to the ASP.NET process, which is a worker process separate from the IIS process model. Then, ASP.NET decides whether to impersonate a user on the thread the request is assigned to, based on the application's configuration. Impersonating the authenticated user isn't the default behavior with ASP.NET, unlike with ASP.