With the release of .NET 4 comes the obsoletion of the policy portion of code access security. If you ignore the compilation warnings (warnings are errors) and attempt to run the afflicted application, you will inevitably encounter exceptions.

NotSupportedException: This method uses CAS policy, which has been obsoleted by the .NET Framework. In order to enable CAS policy for compatibility reasons, please use the <NetFx40_LegacySecurityPolicy> configuration switch.

As the exception suggests, if you’re making your application .NET 4 ready and want to get in an operational state as soon as possible, adding the NetFx40_LegacySecurtyPolicy configuration switch is the solution. Open your application’s configuration file and add the following:

<configuration>
  <runtime>
    <NetFx40_LegacySecurityPolicy enabled="true"/>
  </runtime>
</configuration>

However, the CAS policy system is obsolete and calls to it should be removed. These calls are those that directly manipulate security policy, require CAS policy to sandbox, or make use of the Evidence class.

Calls that are used to determine the permission set or trust level for an assembly or application can now be accessed with the following calls: Assembly.PermissionSet, Assembly.IsFullyTrusted, Assembly.IsFullyTrusted, and AppDomain.IsFullyTrusted. That leaves sandboxing in .NET 4, which is more involved.

Changes are inevitable with a new release of the framework, and unlike the past two major release (3.0, and 3.5), 4 isn’t just additions to .NET 2.0. This is the first I’ve come across as I’ve started moving around, but I will post more upgrade information as I come across it under the tag obsolete.

I wrote earlier about creating a factory method for KeyValuePair<K, V> similar to the factory method in the Tuple class. Like the KVP, a two element Tuple is known as a pair as well. But did you know there exists another Pair class in the .NET Framework?

System.Web.UI.Pair sits in System.Web.dll. It’s the dirtiest class of all as it isn’t even generically-typed. Here is the definition.

[Serializable]
[AspNetHostingPermission(SecurityAction.LinkDemand,
    Level = AspNetHostingPermissionLevel.Minimal)]
public sealed class Pair
{
    public object First;
    public object Second;

    public Pair()
    {
    }

    public Pair(object x, object y)
    {
        this.First = x;
        this.Second = y;
    }
}

I decided to take a look at it in .NET 4 to see if there were any differences. I didn’t expect much as I’m sure it would break many pieces of code, but it would see that Pair should at least inherit from Tuple<object, object> then have its First and Second properties mapped to Item1 and Item2. In an ideal world, Pair would be an alias for Tuple<T1, T2>.

[Serializable]
public sealed class Pair
{
    public object First;
    public object Second;

    [TargetedPatchingOptOut(
        "Performance critical to inline this type of method across NGen image boundaries")]
    public Pair()
    {
    }

    [TargetedPatchingOptOut(
        "Performance critical to inline this type of method across NGen image boundaries")]
    public Pair(object x, object y)
    {
        this.First = x;
        this.Second = y;
    }
}

No such luck on the inheritance hierarchy, but there are a few attribute changes.

First, of all, the AspNetHostingPermission attribute was removed. This is a code access security attribute that grants the minimum permissions required for execution to the caller of this class. I compared the usage of this attribute in System.Web 2.0 and System.Web 4 (there is no inbetween release for that assembly) and it appears that it is being removed from nearly everything. The attribute is still used in a few places, but it is almost completely removed from the System.Web.UI namespace (with the exception of PageParserFilter and Page.get_LastFocusedControl()). I wouldn’t be surprised to see it further deprecated by the time .NET 4 goes live. For reference, I am comparing it with Beta 2.

The next thing you will notice is the addition of the TargetedPatchingOptOut attribute. When you generate a native assembly, this attribute informs the native assembly generator to inline the method across image boundaries. This will improve performance for your native assemblies.

I am disappointed the antiquated Pair class is still in the Framework, but I understand that to change it would cause many people headaches. It is interesting to see how such a benign class has been changed in the process of upgrading System.Web.dll since its last release in 2005.