securitymanager.policyhierarchy() is obsolete, what is its replacement?

Question

SecurityManager.PolicyHierarchy() produces a warning about being obsolete, but I am unable to find what method it is replaced by or how to replace it when used to compare received and present policy levels.

E.g.

SecEnumerator levelEnumerator = SecurityManager.PolicyHierarchy();
while (levelEnumerator.MoveNext())
{
 PolicyLevel Seclevel = levelEnumerator.Current as PolicyLevel;
 if (Seclevel == Init.Seclevel)
 {
      return;
 }
}

For such an application what other method should be used now?

Answer 1

There is no replacement.

As you can see in the documentation page of SecurityManager in MSDN, all and every method related to policies are obsolete. The reason for that is the fact that Policies are now removed from CAS (well, since .Net4). To read more about this check here:

Summary of Changes in Code Access Security

That being said, in the description of this warning there is a good link that provides you with the necessary information required to change your code and suggest possible alternatives:

Code Access Security Policy Compatibility and Migration

Migration: Replacement for Obsolete Calls

To help you better we need to know what you are exactly trying to achieve here. Describe your goal and we might be able to suggest an alternate or replacement.

---

Based on your comment it seems that what you are trying to do is to sandbox a piece of user-inserted code (as you put it) and limit its access. This is not the what CAS should be used for. In fact, there is a clear warning about this type of usages in here:

Code Access Security in .NET Framework should not be used as a mechanism for enforcing security boundaries based on code origination or other identity aspects.

Your code probably should be refactored in a way to retrieve the permissions required by a piece of code using the provided Evidence (being strong name or url, etc) by the SecurityManager.GetStandardSandbox(Evidence) method and then use the returned permissions to load the assembly in a new sandboxed AppDomain using the CreateDomain(String, Evidence, AppDomainSetup, PermissionSet, StrongName[]) method. You can also change these permissions before creating a new domain to have more control over the execution of the code. Following article can help you refactor your application:

How to: Run Partially Trusted Code in a Sandbox

In other words, there are no policies anymore, but you can define, retrieve and execute your code under a specific PermissionSet.