The public language runtime supports a variety of different applications. For example, the run library can run web server applications and console applications, as well as applications with traditional Windows user interfaces.
Each application needs to use a piece of code called the run library to start. Running a library host will load the run library into a process, create an application domain in this process, and then load and execute user code in these application domains.
Host Overview
The .NET framework comes with several common situations, including the hosts used by ASP.NET and hosts used by Microsoft Internet Explorer. The .NET Framework SDK also provides an unmanaged API that can be used to write a custom running library host. For example, you can write a custom runbox host for your application server product for simultaneous operations from multiple users. With custom runtime, customers of the application server can write managed code, which will have high scalability, general-purpose system, multi-language support, automatic memory management. If you use special tools such as debuggers to run the library host, you can access information such as application domains such as running in the process.
Most running library hosts include unmanaged code and hosted code. The non-hosting host code will load the run library into the process when the process begins. When the runtime is loaded into the process, control can be transferred to the host code hosting portion, thereby improving performance. By implementing a part of interacting with user code in the host, a better performance is obtained because the host code is carried out in the hosted environment. If you write the entire host with a non-host code, each time the host code interacts with the user code, it is necessary to convert the non-hosting code into a managed code.
The unmanaged host code is used to configure the public language runtime, load it into the process and convert the program into managed code. The host code hosted section creates the application domain where the user code is running, and the user requests the user request to the created application domain.
Load the run library into the process
Before performing any managed code, the host must first load and initialize the public language runtime. Since the running library has not yet been run in the process, all hosts will start with unmanaged stub. The .NET framework provides a set of unmanaged APIs called host APIs, and hosts can use them to initiate the running library. For more information, see Running the library host interface specification in the "Tool Developer Guide" in the "Tool Developer Guide" in the .NET Framework.
In order to load the run library into the process, the host will call CorbindtoruntimeEx, which is located in the public language of the .NET Framework SDK runs in the library host interface specification. The prototype of CorbindToruntimeEx is located in the Mscoree.h of the "include" directory of the .NET Framework SDK. When CorbindtoruntimeEx is called, the host can set the corresponding value to control the behavior of the loaded runprumeric and basic functions such as garbage recovery and assembly. The host can set the value listed in the table below.
value
Description
Parallel garbage recycling
Specifies whether garbage recycling is performed on the background thread or on the thread running the user code.
For more information, see Running the library host interface specification in the "Tool Developer Guide" in the "Tool Developer Guide" in the .NET Framework.
Loader optimization
Control is to load an assembly in a non-domain-specific manner. If you load an assembly in a non-domain, all application domains in a process can share assembly code and read-only run library data structures.
Server and workstation
Specifies whether to load the internal version of the workstation or the internal version of the server.
For more information, see the public language running library host interface specification in the .NET Framework SDK Tool Developer's Guide.
version
Specifies the running version that will be loaded into the process.
In addition to setting the value described above when CorbindtoruntimeEx is invoked, the host can request the interface pointer to IcorruntimeHost. With this pointer, the host can complete tasks such as setting configuration options and convert to managed host code to create an application domain and perform user code. The host can use IcorruntimeHost to configure all aspects of the running library (such as garbage collection) to load it into the process or register additional events. For example, a host can use getConfiguration to register a callback function (when a specific thread will stop in the debugger, the function receives a notification) or specify the size of the garbage recovery heap.
IcorruntimeHost also provides START and STOP methods to enable hosts to explicitly control the survival of the running library in the process. When the first hosted code is running in the process, the START is implicit; when the process is turned off, the STOP is implicitly invoked. Although the host does not require (usually not) explicitly call these methods, in some cases, it is still useful. For example, when the host runs the entire tube code, it is necessary to uninstall the run library from the process to save memory and other resources, it may need to be explicitly called.
Convert to host code
When the run library is loaded and initialized, the host must be converted from the non-hosting code to a managed code to execute the host code and user code. The host code is usually run in the default application domain. Whenever the run library is initialized, it will automatically create the default application domain. When the process is turned off, the default application domain will be uninstalled. Most hosts are not running user code in the default application domain because it cannot be closed independently of the process.
To convert to a managed code, the host must get a pointer to the default application domain and then load the host's hosted portion into the domain. When the conversion to the hosted code is completed, the host's hosted portion can create other application domains to find user code or more host code.
By calling icrruntimehost :: getDefaultdomain, the host can get the interface pointer to the default application domain. This call will return a pointer to System. AppDomain instance. The type of interface pointer is _Appdomain. Briefly, the host calls the managed hosted hostem.appdomain instance by COM interoperability services to load managed host code into the default domain. When the host gets the pointer to the default domain, you can call a LOAD method of System.AppDomain to load the host's managed section into the default domain.
The host's hosted portion usually contains most of the logic of the host. When the conversion to the hosted code will no longer need a non-hosted host code. Since the user code loaded and the user code is managed, if most of the host is used to realize most of the host, higher performance can be provided. Performance is improved, because the call to the user code is carried out in the hosted environment without having to convert between the non-host code and the managed code each time the host code interacts with the user code.
Determine the application domain boundary
When the host code completes the conversion from the non-host code to the managed code, it must create a new application domain for run the user code. The application domain is the configuration used when the host is isolated during the process. This isolation is necessary to ensure that the code that should not be interactive cannot be interacted. For example, if the code is downloaded from two different Web sites to the Internet Explorer host, they must be isolated. To ensure this isolation, the Internet Explorer host will create an application domain for each site.
The host must determine the boundary location of the new application domain before creating an application domain used to run user code. The influencing factors of this decision include requesting for specific types of access, configuration, security, and codes that can be unmounted to other types. Restrict access to type
The type running in an application domain can discover other types running in this domain and call them directly. However, a type will never find the type running in other application domains, so these types cannot be called. When it is determined where to create a boundary, it is necessary to restrict a specific type of access to other types of access to the main matters that need to be considered.
Configuration settings
The application domain is the basic unit configured in the run. Each application domain has an optional association profile that describes settings related to running code in this domain.
For example, the configuration file can contain a list of directory lists for finding a private assembly, a version binding information of a shared assembly, and a location of the type remotely accessible.
Safety
The host can access security policies and role-based security policies for domain setting code. In this way, the host can control both the authority set granted to the code in a particular domain, and can also set the principles of the current thread and the default principles for role-based security policies.
For example, a host can define an application domain level code access security policy to ensure that only code downloaded from a specific site can only be run in this domain. Alternatively, the host can set a role-based security principle to implement a custom authentication scheme.
Code uninstall
To uninstall the managed code running in the process from memory to use memory for other purposes, the host must uninstall the application domain where code is running. A separate assembly or type cannot be uninstalled. In this regard, when you can uninstall the user code, the host has its own rules. For example, an Internet browser may load managed controls into a domain determined by a site. At this point, the browser may apply the corresponding rules, keep the recently viewed web page in memory so that the "advance" and "back" button respond more quickly. When the browser determines that it is no longer necessary to keep a page in memory, it will delete the application domain, so the code of the hosted control is also deleted.
Create and configure applications
When the host determines the position of the domain boundary according to the conditions described in the previous section, it will create a domain for run the user code using the System.AppDomain type CreateDomain method. Each application domain contains a collection of names / values, and the host can store information about the domain in these name / values. Then, the name / value pairs will be passed as a parameter to createDomain.
The .NET framework defines a large number of attributes that can be understood. The names of these properties are defined by static strings in the System.AppDomain class. The host can define the application domain by setting the properties that itself understands. For example, these properties can control how to isolate code running in different domains. In order to enable the host to define a custom attribute for storing a specific information, the name / value can be extended.
In general, the isolation provided by the application domain has two forms:
Application domains prevent types in a domain from discovering and calling types in other domains, thereby preventing code from running in an application domain affecting other domains. The application domain will depend on such factor: the code has been verified and will not be damaged by memory failure.
Where does the host control run library finds a code to load the code into a specific application domain representative hosts. This is important because it will prevent code from the application unexpectedly impact other applications. The ability to control the scope of the code loading request in this way is very different from Microsoft Win32 and COM. Currently, in Windows, due to any of the applications, any code described in the registry or any code located in a known location (such as a Windows System Directory), the resolution range is the entire computer. Sharing in this way is the current default mode, and this behavior may cause a DLL conflict.
In addition to establishing the scope of the code load method, the range of configuration information must be reduced to an application. However, it is still unob possible for most configuration settings. For example, if you configure a remote computer to run the COM class, the RemoteServerName key settings in the registry in the registry will affect all applications that use this class. Similar to non-intentional code sharing, non-intended sharing configuration data will prevent the application from fully controlling its own behavior.
System.appdomainflags.applicationbase and system.appdomainflags.configurationFile properties Control the following two-way capabilities: Specify the directory of the run library to find assembly; control the configuration setting range of the specific application domain.
ApplicationBase will create an root directory for the application domain, and the run library finds a private assembly in this directory. If the host allows an assembly from disk, it must provide an ApplicationBase that allows the running library to find where to find loaded assemblies.
The ConfigurationFile property specifies the name of the XML file containing the configuration application (these applications running in the application domain). Settings in Application Profiles include assembly version control rules, as well as guides for how to find the types of remote access types in the application domain.
Load and execute user code
The reason why the host is to set up a application environment for running a managed user code. In this context, the user code means any hosted code that is not specifically part of the host. For example, for the Internet Explorer host, the user code is a managed control and script that make up the HTML page. For the application server host, the user code is a code that contains the business rules managed and executed by the application server.
All managed codes are part of the Assembly class. Therefore, methods that can be used to load and run hosted code are based on the assembly. For example, System.Appdomain and System.Reflection.Assembly classes contain methods that make the host to load an assembly. The LOAD method has a variety of forms: Some methods use the assembly name, some methods use the full file system path of the file where the assembly list is located. These methods are used to load assemblies previously created and saved on the disk.
For example, suppose the above application server host allows the user to write managed code business rules to load into the application server process. When a request for a particular service rule is sent to an application server, the server running library host code will determine which domain runs code, or whether you must have a new domain. Then, the run library host code uses an assembly LOAD method to load the assembly containing the business rules and uses reflection to perform the business rules. For more information, see the documentation for System.Reflection NameSpace.
System.Reflection.emit Namespace also provides a type of dynamically created assembly. When the application handles script code, the assembly will be loaded in this way.
For example, a word handler may support a user available a macro language from defining application behavior. When the run library is loaded and created the application domain, the word handler may compile the macro script as a managed code and create an assembly using System.Reflection.emit. Then, you can load the created assembly to run in the application domain. Depending on the specific case, the assembly may only exist in the survival of the application (ie, from being saved to the disk).
Set the security policy of the application domain level
The .NET framework provides both code access security mechanisms, as well as role-based security mechanisms. Due to these two security mechanisms, you can submissively control the code executable operation. It also provides a structure that enables the component to determine the operation that the user can perform. For code running in the application domain created by the host, the host has highly controlled two security mechanisms. When an administrator and host use the code access security mechanism, whether the code is executed in executing the code, the code can be performed according to the characteristics of the code itself. Code characteristics are called evidence, which can include downloading the web site or area of the code, or a digital signature of the release of the supplier.
When loading and running code, the code access security mechanism maps this evidence to a set of permissions. These permissions define the specific operations that can be performed. The administrator or host will map specific evidence to the permissions granted to the code. This mapping is called a security policy. For example, an administrator may create a security policy to grant a set of higher privileges (such as access file system) to the code (such as access file system), and grant a set of lower permissions from the code from the Internet.
The host is a security policy set by the application domain as an application domain security policy. Administrators will also define some strategies at the enterprise, computer, and user level to determine all permissions granted to code, and there is a case between these policies and application domain security policies. Note that application domain policies can only limit the set of permissions granted by higher strategies (enterprise, computer or users).
The host sets the application domain level policy by calling the AppDomain.SetAppDomainPolicy method to the System.AppDomain class. The host can only set the application domain level when it is granted to SecurityPermission to control the evidence.
Set role-based security policies and principles
With role-based security policies, components can identify current users and their associated roles at runtime. This information will then be mapped using the code access security policy to determine the permissions granted at runtime. The host can set a role-based security policy and the current security principle for a given application domain. Safety principles represent the user and the role associated with the user.
Roles-based security policies are often used to implement custom authentication schemes. For example, an ASP.NET host uses a role-based security policy to implement user information authentication scheme, which will be obtained from Internet Information Services (IIS).
The definition of users and user roles is targeted for a particular application. Applications can have different user concepts different from Windows. For example, an application can require a user to provide a username and password when logging in to the application. The username / password is independent of the username / password used by the user logs in to Windows.
The host can set the rules for the current thread by calling the SETTHREADPRINCIPAL method of the System.AppDomain class. The current principle is used as an input to the code access security policy. It determines whether a given principle can perform the specified operation.
The .NET framework provides the concept of default principles. This principle is the principle that is automatically associated with the running thread when the principle is not explicitly set. The built-in value of the default principle includes a Windows user that unused users and currently being using their accounts. The host can change the default principles by calling the SETPRINCIPALPOLICY of the System.AppDomain class.
Uninstall the domain and off process
Application domains can be uninstalled without stopping the entire process. The host can utilize this feature to uninstall the code that is no longer needed, thereby reducing memory occupancy and increases the scientificability of its application.
The System.AppDomain class includes a static method called unload, the host can use this method to uninstall a specific application domain. AppDomain.unload will perform normal shutdown, as long as there is any activity thread, you will not uninstall the domain.
These assemblies cannot be uninstalled if the assembly is loaded into the default domain or is already loaded in the form of a domain, unless you uninstall these assemblies unless you turn off the entire process or uninstall from the process.
The IcorruntimeHost interface includes a method called STOP, and the host can use this method to force uninstall the running library from the process. When the STOP is called, all domains (including the default domain, including the default domain and all non-specialized domains) are immediately uninstalled, and the running libraries are all removed from the process. When the STOP is called for the process, the runtime cannot be loaded back to the process. To start running the managed code again, you must create a new process. to sum up
The above is some of the main features and methods of public run in vs.net, give you a reference. If you have any suggestions, please Mil I Paulni@citiz.net.
