Article ID: 969218 - View products that this article applies to.
This article contains information on the structure of various available .NET Framework specific configuration options in Internet Explorer 6, 7, and 8 security zone settings
Q: Each security zone in Internet Explorer offers the same set of . NET-specific specific configuration options.
Internet Explorer offers the following .NET-specific Internet Explorer configuration options:
1. Options below ".NET Framework"
Q1: What is the meaning of the superior option, .NET Framework, that contains the two options to configure "Loose XAML" and "XAML browser applications," knowing that "XPS documents" are relevant for XPS documents browsed and displayed in Internet Explorer?
A1: See A1.1.
1.1 "Loose XAML" and "XAML browser applications"
Q1.1: What is the meaning of the two options?
How does Internet Explorer differentiate between "loose XAML" and "XAML browser applications"?
A1.1: Loose XAML refers to a .xaml file. These files can be navigated to and viewed in the browser. XAML browser applications are called XBAPs, and have a .xbap extension. The options let the user specify which of these .NET Framework content types are enabled or disabled, or whether to prompt for user consent to run in a particular security zone; for example, in Internet zone, prompt for user consent to run XBAPs, whereas in Intranet zone, simply enable them to run.
XBAPs are online-only WPF applications that run in the browser in a security sandbox. They provide much of the richness and power of WPF with the ease of deployment and navigation-style user experience of being hosted in the browser. XBAPs typically have C# or Visual Basic code behind them. Loose XAML are .xaml files without code behind them that can be run within the browser without compilation.
Loose XAML are .xaml files without code behind them that can be run within the browser without compilation.
2. Options below ".NET Framework-reliant components"
Q2: What does "components" in the above context refer to?
Is this for assemblies in DLLs or EXEs?
A2: This section applies to managed controls in the browser (referenced by an object tag) and HREF-exes (managed applications referenced by a link).
2.1. "Permissions for components with manifests"
Q2.1: This option may be confusing, as the execution of a managed piece of code requires a manifest.
Does this refer only to published ClickOnce applications where a user launches the (native code based) setup by browsing to a URL with the .application extension?
What does "High Safety" mean?
A2.1: This section refers to a new feature added in the .NET Framework 3.5. It allows you to add a ClickOnce-style manifest to a control in the browser. It does not apply to ClickOnce applications. More information is available in the blog post at http://blogs.msdn.com/shawnfa/archive/2008/01/24/manifested-controls-redux.aspx
(http://blogs.msdn.com/shawnfa/archive/2008/01/24/manifested-controls-redux.aspx). That post also includes links to a series of posts covering the feature.
2.2. "Run components not signed with Authenticode"
Q2.2: What does this option mean?
What does "components" refer to?
When is the Authenticode evidence check performed?
Is it done by Fusion or by Internet Explorer internal code?
When does Internet Explorer perform an Authenticode specific evidence check?
When does a custom CAS with publisher based trust come into play?
Does this apply for Authenticode signed setup packages (like MSI or CAB) or to the signature(s) of contained components?
What is the difference when a managed component is deployed by OBJECT tag using the overloaded managed syntax for the classid attribute vs. the 'classic' ActiveX approach with components compiled with ComInterop?
A2.2: See A2.3.
2.3. "Run components signed with Authenticode"
Q2.3: What are the underpinnings (same questions as in Q2.2) for this option?
A2.3: These settings apply only to managed controls (referenced by an object tag using the overloaded managed syntax for the classid attribute) and HREF-exes (managed applications referenced by a link). The Authenticode signature check is done by the CLR and is only checking whether or not the executable referenced by the object tag or link is signed with any Authenticode signature (not a specific Authenticode signature).
2.4. "Enable .NET Framework setup"
Q2.4: What does this option mean?
What practical use does this setting provide?
A2.4: The “Enable .NET Framework setup” setting controls the bootstrapper that will kick off .NET install when users navigate to .xaml/.xbap/.xps/.application content in Internet Explorer, but do not have .NET already installed on their computers.
Article ID: 969218 - Last Review: September 28, 2011 - Revision: 3.0