Datasheet

beyond just page classes. For example, ASP.NET 2.0 dynamically generates a class definition based on
the
<profile /> configuration element and then compiles the resulting class definition. For all these
types of activities, ASP.NET needs a default location for generated code as well as the compiled results
of the auto-generated code.
By default, during application domain initialization, ASP.NET will attempt to create an application
specific code-generation (or codegen for short) directory structure at the following location:
%windir%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\appname
As noted earlier, your Windows path will vary, and the final shipping version of the framework will
have a different version number. The final portion of this directory path will reflect the name of the
ASP.NET application.
By default, when the framework is installed, the local machine group IIS_WPG, the local machine
account ASPNET, and the NT AUTHORITY\NETWORK SERVICE accounts are granted read and write
access (in addition to other security rights) to this temporary directory. As a result, the current security
identity normally has rights to create an application specific code-generation directory. If the current
security identity does not have read and write access to the Temporary ASP.NET Files directory, then
ASP.NET will return an exception to that effect.
If you are running ASP.NET as an interactive user, ASP.NET will fall back and use the operating system’s
temporary directory as the root beneath which it will create code-generation directories. On Windows
Server 2003, the temporary directory structure is rooted at
%windir%\TEMP. You will likely encounter
this situation if a developer uses a file-based web while developing in Visual Studio 2005. File-based
webs use the standalone Cassini web server for running ASP.NET applications and Cassini runs as the
current interactive user. If the interactive user does not have read and write access to the Temporary
ASP.NET Files directory (for example the interactive user is not a machine administrator or a member of
Power Users), then the operating system’s temporary directory structure would be used instead. Again
though, this fallback behavior is limited to only the case where the ASP.NET host is running as an inter-
active user. On most production web servers, this will never be the case.
Setting the Trust Level
As a quick recap of code access security (CAS) concepts, remember that the .NET Framework can use
four levels of code access security policies:
1. Enterprise
2. Machine
3. User
4. Application domain
The first three levels of CAS policy can be configured and maintained by administrators to ensure a
consistent set of CAS restrictions. However, an administrator normally has no ability to configure or
enforce application domain CAS restrictions.
ASP.NET 1.1 introduced the concept of trust levels and exposed a configuration element (
<trust />) as
well as Extensible Markup Language (XML) text files that contain the actual definitions of various
ASP.NET trust levels. Later in the book in Chapter 3 the specifics of the ASP.NET trust level settings will
17
Initial Phases of a Web Request
04_596985 ch01.qxp 12/14/05 7:46 PM Page 17