Medium Trust and Visual Studio codename 'Orcas' Beta 2

Update: Changes were made for the final release of Visual Studio 2008 so that the providerOptions requires are included for new web applications. 

 

There are a couple of issues and complexities with using partial trust in 'Orcas' beta 2.

Below is an article from the team that explains the issues for developers and provides workarounds. The issues and workarounds described apply only to .NET Framework 3.5 Beta 2, and will be addressed in the final version of the product. The first explains what a developer must do to create partial trust applications in 'Orcas'. And the second explains what needs to be done on the server in order to host an ASP.NET application in partial trust that leverages LINQ.

ASP.NET Web applications or sites built with Visual Studio 2008 Beta 2 and .NET Framework 3.5 Beta 2 cannot be run in medium or partial trust

 

When you use Visual Studio 2008 Beta 2 to build a new ASP.NET Web application or website with .NET Framework 3.5, or migrate an existing ASP.NET application or website to .NET Framework 3.5, the resulting application will not run in medium trust or any other partial trust configuration. This issue affects all versions of Visual Studio 2008 Beta 2. A workaround is available below.

Description

To enable support for new compiler features in .NET Framework 3.5, Visual Studio 2008 Beta 2 inserts a new <system.codedom> section into the web.config file of every ASP.NET Web application. The configuration entry looks as follows:

 

    <system.codedom>

      <compilers>

        <compiler language="c#;cs;csharp" extension=".cs"
compilerOptions="/warnaserror-" warningLevel="4"

                  type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">

          <providerOption name="CompilerVersion" value="v3.5"/>

        </compiler>

        <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
compilerOptions="/optioninfer+"

                  type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">

          <providerOption name="CompilerVersion" value="v3.5"/>

        </compiler>

      </compilers>

    </system.codedom>

 

This configuration entry contains a setting called compilerOptions that is not allowed under any partial trust configuration. When you run the application in medium trust or another partial trust setting, ASP.NET will raise an error noting that “the current trust level does not allow the use of the ‘compilerOptions’ attribute”. NOTE: Depending on the security settings of your server, this error message may or may not be visible to you.

 

Workaround

To avoid this problem, you can remove the compilerOptions setting, as well as the warningLevel setting, from this configuration section in your application’s web.config file after you have created or migrated your application. After making the change, your <system.codedom> section should appear as follows:

 

    <system.codedom>

      <compilers>

        <compiler language="c#;cs;csharp" extension=".cs"
type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">

          <providerOption name="CompilerVersion" value="v3.5"/>

        </compiler>

        <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">

          <providerOption name="CompilerVersion" value="v3.5"/>

        </compiler>

      </compilers>

    </system.codedom>

 

The workaround above also has the following impact on your ASP.NET Web applications:

 

1. For websites built with Visual Basic, the workaround prevents using the new LINQ capabilities of .NET Framework 3.5 on an ASP.NET page. To fix this, users can add the following line to the beginning of their Visual Basic codebehind file, and any other Visual Basic code files that use LINQ:

 

Option Infer On

 

Inline Visual Basic inside the .aspx or .ascx page (within a <script runat=”server”> tag) will not be able to use LINQ with this workaround. Users should move this code to a codebehind file. Other ASP.NET page features that use LINQ, such as the LinqDataSource control, will continue to work normally.

 

2. For websites built with C#, compiler warnings will no longer show up in the Visual Studio errors pane on compilation.

 

LINQ features in .NET Framework 3.5 Beta 2 cannot be used by default in medium or partial trust configurations

 

By default, the LINQ features in .NET Framework 3.5 Beta 2 cannot be used in medium trust or partial trust configurations. Enabling LINQ in these configurations requires a machine-level change to .NET Framework configuration.

Description

In medium trust or partial trust configurations, the code permissions granted to an ASP.NET website are determined by a Code Access Security (CAS) policy file on the Web server. When .NET Framework 3.5 is installed on a Web server, websites continue to use the same CAS policy file as .NET Framework 2.0.

 

The LINQ feature set in .NET Framework 3.5 requires the CAS policy file to grant a new permission, called RestrictedMemberAccess, which is not granted by default on ASP.NET 2.0. To enable LINQ to work in medium or partial trust, you need to modify the CAS policy file to grant this additional policy.

 

NOTE: Making this change will also grant this policy to ASP.NET 2.0 websites running on the same server. We have determined this to be an acceptable change for hosted sites that run under medium trust. This change will have no impact on existing ASP.NET 2.0 websites that can run under medium or partial trust.

Workaround

To enable LINQ for medium trust, please follow the steps below on the server:

1. Open a command prompt, and go to the directory that contains your ASP.NET 2.0 trust policy files. This can be found under the Windows directory, at

 

%windir%\Microsoft.NET\Framework\v2.0.50727\config

 

2. Determine which CAS policy file to modify. If you are using medium trust, this file will be web_mediumtrust.config.

 

3. Make a backup of the existing file.

 

4. Examine the <SecurityClasses> section of your CAS policy file. If the section does not contain an entry named ReflectionPermission, add a new entry as follows:

 

<SecurityClass Name="ReflectionPermission" Description="System.Security.Permissions.ReflectionPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>

 

If you are using the default medium trust settings, you will need to add this entry. Depending upon your trust setting, your CAS policy file may already contain this entry.

5. Examine the <NamedPermissionSets> section of your CAS policy file. If the section does not contain an entry named ReflectionPermission, add a new entry as follows:

 

<IPermission

        class="ReflectionPermission"

        version="1"

        Flags="RestrictedMemberAccess"

/>

If you are using the default medium trust settings, you will need to add this entry.

 

If you are using another trust configuration, and the section already contains an entry named ReflectionPermission, you can modify the Flags setting to add RestrictedMemberAccess permission. Flags should be separated by a comma. For example, if you are using the default high trust settings, you can modify this section as follows:

<IPermission

        class="ReflectionPermission"

        version="1"

        Flags="ReflectionEmit, RestrictedMemberAccess"

/>

 

6. Save the file, and restart the Web server.