Per dotnet/designs#139, we want to obsolete some of the CAS-related APIs in .NET 5.0. The obsoleted APIs are primarily classes that derive from CodeAccessSecurityAttribute and CodeAccessPermission.

The fixer should help apps migrate away from these now-obsolete types.

For CodeAccessSecurityAttribute-derived which are obsolete (except PrincipalPermissionAttribute), the fixer should look at the SecurityAction parameter passed into the attribute ctor. If the value is one of SecurityAction.Assert, Demand, InheritanceDemand, LinkDemand, RequestMinimum, or RequestOptional, the fixer should recommend that the attribute declaration be removed entirely. If the SecurityAction enum value is anything else, the fixer should make no recommendation.

For CodeAccessPermission-derived types which are obsolete (n.b. PrincipalPermission does not subclass this type and should be excluded), the fixer should suggest calls to Assert and Demand be removed. If any other API is called, the fixer should make no recommendation.

Examples:

// fixer should recommend removal
[SecurityPermission(SecurityAction.Demand, ...)]
public void SomeMethod() { /* ... */ }

// fixer should NOT recommend removal
// dev needs to take a closer look at what they were trying to accomplish
[SecurityPermission(SecurityAction.Deny, ...)]
public void SomeMethod() { /* ... */ }

// note: this is already obsolete *as error*
// fixer should NOT recommend removal
// dev needs to take a closer look at what they were trying to accomplish
[PrincipalPermission(SecurityAction.Demand, ...)]
public void SomeMethod() { /* ... */ }

public void SomeMethod()
{
    // fixer should recommend removal of this line
    new SecurityPermission(...).Demand();

    // fixer should NOT recommend removal
    // dev needs to take a closer look at what they were trying to accomplish
    // n.b. this call will always result in PNSE at runtime
    new SecurityPermission(...).Deny();

    // fixer should NOT recommend removal; PrincipalPermission does not subclass CodeAccessPermission
    // dev needs to take a closer look at what they were trying to accomplish
    new PrincipalPermission(...).Demand().
}

For PrincipalPermissionAttribute and PrincipalPermission specifically, we should steer the developer toward using ASP.NET's built-in AuthN / AuthZ features.