.NET Framework Administrator Overview

.NET Framework Administrator Overview

This is preliminary documentation and subject to change.
Send feedback on this topic.

This help file is written for the system administrator who is managing .NET Framework applications running on a server. It provides an overview of the .NET Framework and links to a vast array of information on the Web, including the .NET Framework SDK. As an aid to help you locate the information that interests you most, the following section lists and describes the main areas of the documentation.

In This Section

.NET Framework Overview
Provides a brief overview of the .NET Framework, including ASP.NET and Windows Forms, and contains links to the .NET Framework SDK.
Administering .NET Framework Security Policy
Discusses security considerations when working with ASP.NET and other .NET Framework applications.
.NET Framework Configuration Files Overview
Provides an overview of the various configuration files associated with .NET Framework applications.

Related Sections

.NET Framework SDK documentation
Provides a comprehensive set of documentation on the .NET Framework.


.NET Framework Overview

The .NET Framework is a new computing platform designed to simplify application development in the highly distributed environment of the Internet. It is a standards-based, multilanguage application execution environment that handles many essential resource management tasks and simplifies deployment. The .NET Framework manages memory, addresses versioning issues, and improves the reliability, scalability, and security of applications.

The .NET Framework has several main components: the common language runtime, the .NET Framework class library, and the runtime hosts.

  • The common language runtime is the foundation of the .NET Framework; it manages code execution and provides core services such as memory management, thread management, and remote execution.
  • The .NET Framework class library is a comprehensive, object-oriented collection of reusable classes that you can use to develop a wide range of applications, including ASP.NET applications and XML Web services.
  • The .NET Framework provides several runtime hosts, including Windows Forms for Win32-like applications and ASP.NET, which works directly with the runtime to provide a scalable, server-side environment for managed code.

For a system administrator, the .NET Framework means new, more powerful applications that are easier to deploy and maintain. These new applications have new ways to control security and application configuration. Third-party applications can update their applications by using configuration files that point to new parts of the application, or they may require the system administrator to edit an existing configuration file.

The runtime can be run concurrently (also called side-by-side), meaning that new versions of the runtime do not replace the old version but rather are installed in addition to the old version. For example, suppose that Microsoft Windows .NET Server ships with a version of the runtime such as version 1.0.0.0. Then Microsoft ships a new version, such as version 1.0.1.1, which you download and install. This new version of the runtime does not overwrite the previous version, but rather installs on the computer along with 1.0.0.0. This allows older applications built using an older version of the runtime to continue working after you install a new version of the runtime. New applications can target either version, depending on a number of parameters and machine configurations, as well as the application’s settings.

See Also

See the following topics in the .NET Framework SDK documentation: Overview of the .NET Framework and ASP.NET QuickStart.


ASP.NET and XML Web Services

ASP.NET is the next generation of Active Server Pages (ASP) technology. While ASP.NET is largely syntax compatible with ASP, it also provides a new programming model and infrastructure that allows you to create a powerful new class of applications, and it provides robust XML support.

In ASP.NET, code is compiled. When a user requests a page the first time, the runtime compiles the code and the page itself, and keeps a cached copy of the compiled result. When a user requests the page a second time, the cached copy is used. This results in greatly increased performance because, after this first request, the code can run from the much faster compiled version and the content on the page does not need to be parsed again.

ASP.NET allows you to use and create XML Web services. XML Web services provide the building blocks for constructing distributed Web-based applications. An XML Web service is an application delivered as a service that can be integrated with other XML Web services using Internet standards. For example, a company can assemble an online store by using the Microsoft Passport service to authenticate users, a third-party personalization service to adapt Web pages to each user's preferences, a credit-card processing service, a sales tax service, package-tracking services from each shipping company, and an in-house catalog service that connects to the company's internal inventory management applications.

ASP.NET files have an .aspx file extension, while XML Web services have an .asmx extension. The technologies are similar; however, instead of outputting HTML, an XML Web service outputs a computer-readable answer to the input it receives.

ASP.NET has many benefits over ASP for the system administrator:

  • Configuration and deployment are now easier with the use of human-readable configuration files and DLLs that do not need to be registered.
  • All the configuration details for all Web applications are kept in human-readable files named Web.config. The standard format for the configuration files is XML, and each application inherits the settings in the default Web.config file.
  • All files that a Web site needs are located under the site's root folder. DLLs are in the /bin folder, and the Web.config file is in the root folder. To deploy a Web application, all you need to do is copy the site's root folder by using file copy commands, the Microsoft FrontPage® server extensions, or FTP.
  • Files that run from the /bin directory are actually run from copies of the files. If you need to update the ASP.NET application, all you have to do is copy over the old files with the new ones. The DLLs are not locked when in use, and ASP.NET detects the new files and restarts the application using the new DLLs automatically.
  • In ASP, the only type of authentication that you can use is Windows authentication, whereas ASP.NET allows different types of logon and user authentication, including Windows, Passport, and cookies.
  • ASP.NET has several features that improve reliability, including automatic application recycling. In addition, ASP.NET includes several performance monitors.

The system administrator may be required to update the configuration files that are part of an ASP.NET application. In addition, security settings and machine configuration files may also need to be updated over time. Finally, configuration files may need to be changed when an update to an application is received.

See Also

See the following topics in the .NET Framework SDK documentation: ASP.NET QuickStart, Creating ASP.NET Web Applications.


Windows Forms

Windows Forms is a robust programming environment for building Win32 client applications. It provides great support for Win32 developers, improved ease-of-use and reliability, and easier deployment. Windows Forms allows you to create Windows-based applications using the .NET Framework. This framework provides a clear, object-oriented, extensible set of classes that enable you to develop rich Windows applications. Additionally, Windows Forms can also act as the local user interface in a multitier distributed solution.

See Also

See the following topics in the .NET Framework SDK documentation: Introduction to Windows Forms


Administering .NET Framework Security Policy

The .NET Framework provides a code access security model that allows administrators to modify security policy to meet their individual needs. While code access security generally increases the reliability and security of applications, improperly administering code access security policy can potentially create security weaknesses.

The .NET Framework security system is governed by a configurable set of rules called security policy. This policy allows the end user or administrator to adjust the settings that determine which resources code is allowed to access, and ultimately decide which code is allowed to run at all.

For example, suppose you are an administrator in an enterprise setting and you do not trust the software that originates from a particular company. Perhaps that company produces software that employees find entertaining, but which causes increased network traffic or causes workstations to become unstable. You can set an enterprise level security policy that restricts the access that software has to your computer resources. You can also set a policy that prevents this publisher's software from running at all.

Evidence, Code Groups, and Permission Sets

Code that targets the common language runtime is deployed in units called assemblies. At load time, the runtime examines each assembly for evidence, which is identifying information about the assembly (such as the digital signature of the code's author and the location where the code originates). Based on the evidence, the common language runtime security manager maps the assembly to a code group based on security policy. Code groups are defined to test for specific forms of evidence and have permission sets associated with them. Assemblies that belong to a code group receive the permissions defined by the associated permission sets. For more information about evidence, code groups, and permission sets, see Security Policy Model in the .NET Framework SDK documentation documentation.

Permissions

Permissions are simply objects created by an application that represent the right to access a protected resource. Permissions are configurable and a single permission object can assume several forms. The rights that a permission represent and that assemblies receive are fully configurable by the system administrator. While applications can construct and configure permission objects like any other object, only security policy can grant a permission to an application. Administrators ultimately control the permission grant. For a list of common permissions, see Code Access Permissions in the .NET Framework SDK documentation documentation.

Security Policy Levels

There are four levels of security policy defined in the security model, which correspond to the different administration and hosting scenarios. The following table describes each level. The enterprise policy level is the highest level and the application domain level is the lowest.

Policy level | Description | Corresponding configuration file
Enterprise policy | Defined by enterprise administrators who set policy for enterprise domains. | %CLR installDir%\Config\Enterprise.config
Machine policy | Defined by machine administrators who set policy for one computer. | %CLR InstallDir%\Config\Security.config
User policy | Defined by users who set policy for a single logon account. | %USERPROFILE%\Application data\Microsoft\CLR security config\vxx.xx\Security.config
Application domain policy | Defined by the runtime host (any application that hosts the common language runtime) for setting load-time policy. This level cannot be administered. | None

Each policy level consists of a hierarchy of code groups. Administrators of each policy level can create their own code groups and associated permission sets. At load time, the code access security system examines all policy levels and the resulting permission grant is the intersection of all allowed permissions in each level. Administrators of a lower policy level cannot loosen a policy decision made on a higher level, but they can tighten policy as much as they want. The default security policy resides on the machine policy level.

The default security settings are as follows:

  • User and enterprise levels are set to unrestricted.
  • The machine level contains the specific policy settings and restrictions.
  • The settings defined by all three levels constitute default settings.

Note that unrestricted user and enterprise levels do not result in unrestricted permissions being granted to an assembly. Because the machine level defines several restrictions, and all three levels are considered as a whole, the resulting permission grant is not unrestricted permission.

See Also

See the following topics in the .NET Framework SDK documentation: Security Policy Management, Security Tools, Default Security Policy, Code Access Permissions, Security Policy Model.


.NET Framework Configuration Files Overview

The .NET Framework gives developers and administrators control over how applications run. The .NET Framework uses configuration files to control, for example, which protected resources an application can access, what version of an assembly (an application component) an application uses, and where remote applications and objects are located. These human-readable, XML-based files give system administrators the ability to manage applications on an individual computer or on all computers across an enterprise.

There are several .NET Framework configuration files, and each file has a different scope. The machine and application configuration files follow the same syntax and provide information such as binding redirects, the location of code, and binding modes for particular assemblies. Security configuration files are used to set security policy, and can be set on a per-user, per-machine, and per-enterprise basis.

In This Section

Computer Configuration
Discusses the machine configuration file, Machine.config file, which is used to specify machine-wide settings for applications.
Security Configuration
Briefly describes the configuration files used to set security policy.
Application Configuration
Describes the application configuration file, which is used to set application-specific settings.
Configuring ASP.NET Applications
Discusses how to configure ASP.NET applications.
.NET Framework Configuration Tool
Describes the configuration tool provided in the .NET Framework SDK.
Code Access Security Policy Tool
Discusses the console application for setting and changing security policy.

Related Sections

.NET Framework SDK documentation
Links to the main topic page of the .NET Framework SDK.


Computer Configuration

Each computer with the .NET Framework installed has a machine configuration file. This file, named Machine.config, contains settings that apply to the entire computer. It is located in the %runtime install path%\Config directory. Machine.config contains configuration settings for machine-wide assembly binding, built-in remoting channels, and ASP.NET.

The Machine.config file can be used by administrators to specify assembly binding restrictions that are local to that computer. The settings in the machine configuration file take precedence over all other configuration settings; however, this does not mean that all configuration settings should be put in this file. Some settings in the machine configuration file cannot be changed by other configuration files. For example, the common language runtime version specified in the machine configuration file is final, and cannot be overridden. Overrides specified in the Machine.config file affect all applications.

See Also

See the following topics in the .NET Framework SDK documentation: Machine Configuration Files, Configuration Files.


Security Configuration Files

The security configuration files for the .NET Framework consist of three XML-based files. While the machine configuration and application configuration files contain XML elements dealing with runtime versions and assembly binding, the security configuration files contain only XML elements that apply to security policy. These XML files are used to configure code groups and permission sets that affect .NET Framework security policy. For an overview of .NET Framework security policy, see Administering .NET Framework Security Policy in the .NET Framework SDK documentation.

Security policy is expressed using three policy levels: machine policy, user policy, and enterprise policy, and these three policy levels correspond to the three security configuration files.

Policy level | Corresponding configuration file
Enterprise policy | %CLR installDir%\Config\Enterprise.config
Machine policy | %CLR InstallDir%\Config\Security.config
User policy | %USERPROFILE%\Application data\Microsoft\CLR security config\vxx.xx\Security.config

The set of permissions that an assembly receives is determined by the intersection of the permission sets allowed by these three policy levels. Each policy level is represented by a hierarchical structure of code groups. Every code group has a membership condition that determines which code is a member of that group. A named permission set is also associated with each code group. This permission set specifies the permissions the runtime allows code that satisfies the membership condition to have. A code group hierarchy, along with its associated named permission sets, defines and maintains each level of security policy.

See Also

See the following topics in the .NET Framework SDK documentation: Security Policy Management, Key Security Concepts, .NET Framework Configuration Tool.


Application Configuration Files

An application configuration file contains settings specific to an application. This file contains configuration settings used by the common language runtime, such as assembly binding policy and remote object location, as well as settings used by the application.

The common language runtime checks the application configuration file for information that overrides the version information from the application. The application configuration file can be deployed with an application, but is not required for application execution. Usually, the retrieval by the runtime of this file is almost instantaneous, but in situations where the file is on a remote computer, such as in an Internet Explorer Web-based scenario, the configuration file must be downloaded.

The name and location of the application configuration file depend on the application's runtime host, which can be one of the following:

  • Executable–hosted application.

    The configuration file for an application hosted by the executable host is located in the same directory as the application. The name of the configuration file is the name of the application with a .config extension. For example, an application called myApp.exe could have a configuration file called myApp.exe.config.

  • ASP.NET-hosted application.

    ASP.NET configuration files are named Web.config. Configuration files for ASP.NET applications inherit the settings of configuration files in the URL path. For more information about ASP.NET configuration files, see Configuring ASP.NET Applications.

  • Internet Explorer-hosted application.

    If an application hosted in Internet Explorer has a configuration file, the location of this file is specified by an HTML <link> tag that points to a URL.

See Also

See the following topics in the .NET Framework SDK documentation: Configuring .NET Framework Applications, Common Language Runtime Configuration Settings.


Configuring ASP.NET Applications

The ASP.NET configuration system features an extensible infrastructure that defines configuration settings at the time the ASP.NET application is first deployed, and allows administrators to add or revise configuration settings at any time with minimal impact on operational Web applications and servers.

The ASP.NET configuration system provides the following benefits:

  • Configuration information is stored in XML-based text files. Any standard text editor or XML parser can be used to create and edit ASP.NET configuration files.
  • Multiple configuration files, all named Web.config, can appear in multiple directories on an ASP.NET Web application server. Each Web.config file applies configuration settings to its own directory and all child directories below it. Configuration files in child directories can supply configuration information in addition to that inherited from parent directories, and the child directory configuration settings can override or modify settings defined in parent directories. The machine configuration file provides ASP.NET configuration settings for the entire server.
  • At run time, ASP.NET uses the configuration information provided by the Web.config files in a hierarchical directory structure to compute a collection of configuration settings for each unique URL resource. The resulting configuration settings are then cached for all subsequent requests to a resource.
  • ASP.NET detects changes to configuration files and automatically applies new configuration settings to Web resources affected by the changes. The server does not have to be rebooted for the changes to take effect. Hierarchical configuration settings are automatically recalculated and recached whenever a configuration file in the hierarchy is changed.
  • The ASP.NET configuration system is extensible. You can define new configuration parameters and write configuration section handlers to process them.
  • ASP.NET protects configuration files from outside access by configuring Internet Information Services (IIS) to prevent direct browser access to configuration files. HTTP access error 403 (forbidden) is returned to any browser attempting to directly request a configuration file.

See Also

See the following topics in the .NET Framework SDK documentation: Format of ASP.NET Configuration Files, ASP.NET Configuration.


.NET Framework Configuration Tool

Several security and assembly binding settings found in configuration files can be set using the .NET Framework Configuration tool (Mscorcfg.msc). This Microsoft Management Console (MMC) plug-in can be found by clicking Start, pointing to Administrative Tools, then selecting Microsoft .NET Framework Configuration.

The recommended way to configure security policy is to use the .NET Framework Configuration tool. The following table describes the tasks you can perform with.NET Framework Configuration tool.

Task | Description
New | Create a new security policy file. Use this option to create and deploy new policy level files without affecting policy on the current computer.
Open | Open a policy level. Use this option to open security policy files you created using the New option.
Reset All | Reset all policy levels to the default.
Adjust Security | Adjust the security level for each zone.
Evaluate Assembly | View the permissions granted to an assembly or the code groups that grant permissions to an assembly.
Trust Assembly | Assign a level of trust to an assembly.
Create a Deployment Package | Create and deploy security policy across a network.

The .NET Framework Configuration tool provides several wizards to help you safely adjust your user, machine, and enterprise security settings. The following table describes these wizards.

Wizard | Description
Trust an Application | Use this wizard to identify an application by publisher or strong name information and increase the application's level of trust.
Adjust Security Settings | Use this wizard to increase or decrease permissions to assemblies originating from one of the following zones: My Computer, Local Intranet, Internet, Trusted Sites, or Untrusted Sites.
Create a Deployment Package | Use this wizard to create a Windows Installer package to deploy security policy across an enterprise.

If the wizards do not provide the functionality you require to administer security policy, you can edit the permission sets and code groups directly by using either the .NET Framework Configuration tool or the Code Access Security Policy Tool (Caspol.exe). Caspol.exe is a command-line tool provided mainly for scripting security administration.

See Also

See the following topics in the .NET Framework SDK documentation: Security Policy Configuration, Configuring Security Policy Using the .NET Framework Configuration Tool (Mscorcfg.msc), Code Access Security Policy tool (Caspol.exe).


Code Access Security Policy Tool

The Code Access Security Policy Tool (Caspol.exe) enables administrators to modify security policy for the machine policy level, the user policy level, and the enterprise policy level. The tool is a console-based application that can be used by typing in parameters or to process batch file security changes.

Three security configuration files correspond to the three policy levels supported by Caspol.exe: one for the machine policy, one for a given user’s policy, and one for the enterprise policy. These are the only files affected when using the Code Access Security Policy Tool.

Changes made using the Code Access Security Policy Tool affect only the configuration files of the runtime version that Caspol.exe was installed with. If you run the Caspol.exe that was installed with version X of the runtime, the changes apply only to that version of the runtime. Other concurrent (side-by-side) installations of the runtime, if any, are not affected. If you run Caspol.exe from the command line without being in a versioned runtime directory, the tool is executed from the first runtime directory in the path (which is usually the most recent runtime version installed).

See Also

See the following topics in the .NET Framework SDK documentation: Configuring Security Policy Using the .NET Framework Configuration Tool (Mscorcfg.msc), Code Access Security Policy tool (Caspol.exe).


Topic Not Found

No matching topic was found. The link may be out of date, incorrectly authored, or the topic may not be available in this release.

You may be able to find the topic by using the index or search tab instead.