Deploying a Runtime Application Using Internet Explorer
Web-based applications can use Microsoft Internet Explorer 5.5 or later to download and run assemblies. A Web-based application can download both types of standard portable executable (PE) files — .exe or .dll. An HTML document can provide information on which assemblies to download, the assemblies' locations, and the location of a configuration file that can provide additional information.
A benefit of using Internet Explorer for deploying an application is that assemblies are downloaded only when they are used. If the application consists of multiple assemblies, assemblies are downloaded only when referenced. This automatic process provides faster initial download of an application since the entire application does not have to be downloaded, and the client receives only code it uses.
Note
Code deployed from the Internet typically has the default Internet permissions set by security policy. These permissions allow code to perform only a limited set of functions. For more information about default Internet security policy, see Security Policy.
Web-Based Application Settings
By default, the common language runtime creates an application domain for each site accessed using Internet Explorer. Application domains isolate separate applications that run within a process. The way in which application domains are created affects the permissions that assemblies have when running in the domain. Each application domain is associated with URL evidence and an application base, and might also have a configuration file.
URL Evidence
URL evidence is assigned to applications deployed using Microsoft Internet Explorer 5.5 or later. The runtime host uses this URL evidence to make decisions based on security policy. Although URL evidence is associated both with assemblies that make up the application and with the application domain the application creates, the format for the evidence is different in each case. For an assembly, the URL evidence is the full URL path to the main assembly file. For example, an assembly that is part of an application could have the URL evidence of http://www.code.microsoft.com/myApp/myAssembly.dll. The URL evidence for the application domain is equivalent to the site evidence. Using the previous example, the URL evidence for the application domain would be http://www.code.microsoft.com/.
Note
The location of the application configuration file does not influence URL evidence for the application domain.
Configuration Files
Web applications deployed using Internet Explorer can use information stored in an application configuration file. The application configuration file must be on the Web server in the same directory as the application executable. The application configuration file must follow the naming rules of application configuration files. The file must have the same name as the executable, with the extension .config appended to it. For example, and application called myApplication.exe would have an application configuration file called myApplication.exe.config.
ASP.NET applications specify configuration information using a web.config file. Web applications can supply configuration information, just as ASP.NET and an executable host do. If an application hosted in Internet Explorer has a configuration file, the location of the configuration file is specified in a <link> tag with the following syntax:
<LINK REL="CONFIGURATION" HREF="[configuration file name]"></LINK>
In this example, [configuration file name] is the name of the configuration file, for example:
<LINK REL="CONFIGURATION" HREF="two.dll.config"></LINK>
For basic Web application scenarios, where the Web page does not provide a <link> tag to a configuration file, the runtime creates an application domain on a per-site basis. That is, if the HTML document resides on http://www.code.microsoft.com/myApp/mypage.htm, the application domain is created over the entire site http://www.code.microsoft.com. Note that while this scenario is convenient for the Web author, all Web pages that use managed code assemblies on this site share the same application domain because no configuration file was specified.
If the application reads information from an application configuration file, you must do the following:
Place the configuration file in the same location as the executable.
Permit anonymous access to the Web site, and the directory containing the configuration file must allow script execution.
In a more complex scenario, two or more disparate applications might be required to run on the same site, yet be isolated from each other. To achieve this isolation, the Web page author must specify a configuration file in the HTML document. All pages that point to the same configuration file are created in the same application domain. In this way, it is possible to create an application domain on a per-configuration-file basis.
Note
The runtime does not support the character '#' in URLs that point to a configuration file when the <link> tag contains a relative path.
Application Base
The ApplicationBase is an application domain property that specifies the directory that serves as the root directory when the runtime searches for assemblies. By default, the ApplicationBase property is assumed to be the root of the site (for example, wwwroot). If an application configuration file is present, the ApplicationBase becomes the location of the configuration file. The configuration file can contain configuration information specific to the code running in the application domain. If you have more than one site defined on a machine, the ApplicationBase defaults to the "default" site defined on port 80.
Downloading Managed Executables
While most applications downloaded using the <object> tag are UI controls that appear on the Web page, the runtime also supports two scenarios for downloading managed executables:
A user types the URL of a managed .exe file into the browser; for example:
http://www.server.microsoft.com/MyWebSite/MyApp.exe.An HTML page contains a link to a managed executable; for example:
HREF="MyApp.exe".
In both scenarios, the runtime creates a new application domain in which to run the executable. For subsequent requests for assemblies, the application base is set to the location of the executable.
For example, the following code references myClass:
<object id="myCtl"
classid="http://www.mycode.Microsoft.com/mycode.dll#myClass">
</object>
Dependent assemblies that are statically linked must be located in the same directory as the calling assembly when the calling assembly is specified using the <object> tag. For example, if the assembly myAssembly.dll is specified using an <object> tag and has a static reference to myOtherAssembly.dll, then myOtherAssembly.dll must be located in the same directory as myAssembly.dll.
Note
Managed code executables deployed by Internet Explorer using an HREF link should not be started with command line arguments. Arguments are not successfully passed to the executable.
Error Reporting
The code download process uses the following two registry settings to control error reporting from managed code executables that are deployed using Internet Explorer.
HKLM\Software\Microsoft\.NETFramework\ExposeExceptionsInCOM
HKCU\Software\Microsoft\.NETFramework\ExposeExceptionsInCOM
Both settings use the following values to specify how to report errors.
Value |
Description |
|---|---|
1 |
Error information is sent to the standard output stream. |
2 |
Error information is displayed to the user. |
3 |
Error information is both sent to the standard output stream and displayed to the user. |
When you debug managed code that you deploy using Internet Explorer, you can use the values of these settings to find detailed information about code download failures. For example, this allows you to view stack trace information when exceptions are thrown, instead of relying on the error-reporting provided by Internet Explorer, which was designed for end-users, not developers.
Controls Hosted in Internet Explorer
You can use Internet Explorer to host controls created using the .NET Framework. Controls must be contained in a library with a .dll extension. To use the same Windows Form control as both a standalone and hosted in Internet Explorer, the library must have a .dll extension to work in both cases.
.gif "Important note") Important Note: |
|---|
All managed controls hosted by Internet Explorer use the latest version of the common language runtime installed on the computer. This means that in some instances the control may not run against the version it was built, and the control may not be running under the same security policy as originally intended. Before running a managed control under a new version of the common language runtime, the security policy must be updated for the new runtime version. This applies to any security zone, but does not apply to downloaded managed executables. |
Note
When loading a managed control, the maximum length of the value for the classid attribute of the <object> element is 256 characters (MAX_PATH). If the length is greater than the maximum, the control does not load but no error is generated. For example, the following classid attribute value is an acceptable length:
<object id="myCtl" classid="http://www.example.com/mycode.dll#myClass">
Note
For security reasons, managed controls using the <object> tag and file access protocol in an HTML page are not supported. For example, the following <object> tag is not supported:
<OBJECT classid="file:///c:/control.dll#control">
Locating Dependent Assemblies
The process the runtime uses to locate dependent assemblies for Web-based applications is similar to the process it uses for non-Web-based applications. The runtime searches for private dependent assemblies using a path relative to the ApplicationBase. The runtime uses a combination of the ApplicationBase, the <private_binpath> tag in a configuration file, and searching rules to locate private assemblies. The runtime also checks the URL where the calling assembly is located to check for dependent assemblies.
Signing Managed Code with a Microsoft Authenticode Signature
You can use the File Signing Tool (Signcode.exe) to sign a file with an Authenticode digital signature. Note that if you want to sign a file with both a strong name and an Authenticode digital signature you must assign the strong name first. Assigning the Authenticode signature first breaks the strong name. For more information about file signing, see Assembly Security Considerations. For information about file signing using Visual Studio 2005, see "Deployment and Authenticode Signing" in the Visual Studio 2005 documentation. For more information about the Authenticode signing technology, see "Introduction to Code Signing" in the Platform SDK documentation.
See Also
Concepts
Deployment Scenarios for .NET Framework Applications
Assembly Security Considerations
How the Runtime Locates Assemblies