Compatibilité de la stratégie de sécurité d'accès du code et migration

La partie stratégie de la sécurité d'accès du code (CAS, Code Access Security) est devenue obsolète dans le .NET Framework version 4. En conséquence, il est possible que vous rencontriez des avertissements de compilation et des exceptions runtime si vous appelez des types et membres explicitement ou implicitement (via d'autres types et membres).

Vous pouvez éviter les avertissements et les erreurs comme suit :

• En migrant vers les remplacements .NET Framework 4 des appels obsolètes.

  - ou -

• À l'aide de l'élément de configuration <NetFx40_LegacySecurityPolicy> pour opter pour le comportement de stratégie CAS hérité.

Cette rubrique contient les sections suivantes :

• Utilisation explicite

• Utilisation implicite

• Erreurs et avertissements

• Migration : remplacement des appels obsolètes

• Compatibilité : utilisation de l'option de stratégie CAS héritée

Utilisation explicite

Les membres qui manipulent directement la stratégie de sécurité ou requièrent que la stratégie CAS soit utilisée en mode Bac à sable (sandbox) sont obsolètes et généreront par défaut des erreurs.

En voici quelques exemples :

• AppDomain.SetAppDomainPolicy

• HostSecurityManager.DomainPolicy

• PolicyLevel.CreateAppDomainLevel

• SecurityManager.LoadPolicyLevelFromString

• SecurityManager.LoadPolicyLevelFromFile

• SecurityManager.ResolvePolicy

• SecurityManager.ResolveSystemPolicy

• SecurityManager.ResolvePolicyGroups

• SecurityManager.PolicyHierarchy

• SecurityManager.SavePolicy

Utilisation implicite

Plusieurs surcharges de chargement d'assembly génèrent des erreurs du fait de leur utilisation implicite de stratégie CAS. Ces surcharges prennent un paramètre Evidence utilisé pour résoudre la stratégie CAS et fournissent un jeu d'autorisations pour un assembly.

Voici quelques exemples. Les surcharges obsolètes sont celles qui prennent Evidence comme paramètre :

• Activator.CreateInstanceFrom

• AppDomain.CreateInstanceFrom

• AppDomain.CreateInstanceAndUnwrap

• AppDomain.DefineDynamicAssembly

• AppDomain.ExecuteAssemblyByName

• AppDomain.Load

• Assembly.LoadFrom

• Assembly.Load

• Assembly.LoadFrom

Erreurs et avertissements

Les types et membres obsolètes produisent les messages d'erreur suivants lorsqu'ils sont utilisés. Notez que le type System.Security.Policy.Evidence lui-même n'est pas obsolète.

Avertissement au moment de la compilation :

warning CS0618: '<API Name>' is obsolete: 'This method is obsolete and will be removed in a future release of the .NET Framework. Please use <suggested alternate API>. See <link> for more information.'

Exceptions runtime :

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. Please see <link> for more information.

Migration : remplacement des appels obsolètes

Détermination du niveau de confiance d'un assembly

La stratégie CAS est souvent utilisée pour déterminer le jeu d'autorisations ou le niveau de confiance d'un assembly ou d'un domaine d'application. Le .NET Framework 4 expose les propriétés utiles suivantes qui n'ont pas besoin de résoudre la stratégie de sécurité :

• Assembly.PermissionSet

• Assembly.IsFullyTrusted

• AppDomain.PermissionSet

• AppDomain.IsFullyTrusted

Utilisation de bac à sable (sandbox) pour les domaines d'application

La méthode AppDomain.SetAppDomainPolicy est généralement utilisée pour la mise en bac à sable (sandbox) des assemblys dans un domaine d'application. Le .NET Framework 4 expose des membres qui n'ont pas besoin d'utiliser PolicyLevel à cet effet. Pour plus d'informations, consultez Comment : exécuter du code d'un niveau de confiance partiel dans un bac à sable (sandbox).

Détermination d'un jeu d'autorisations sécurisé ou raisonnable pour le code d'un niveau de confiance partiel

Les hôtes doivent souvent déterminer les autorisations qui sont appropriées pour l'utilisation de bacs à sable (sandbox) pour le code hébergé. Avant le .NET Framework 4, la stratégie CAS permettait de le faire avec la méthode SecurityManager.ResolvePolicy. À la place, le .NET Framework 4 fournit la méthode SecurityManager.GetStandardSandbox, qui retourne un jeu d'autorisations standard sécurisé pour les preuves fournies.

Scénarios autres que le mode Bac à sable (sandbox) : surcharges pour les chargements d'assemblys

La raison de l'utilisation d'une surcharge de chargement d'assembly peut être d'utiliser des paramètres qui ne sont pas autrement disponibles, au lieu d'utiliser le sandbox pour l'assembly. À partir du .NET Framework 4, les surcharges de chargement d'assembly qui ne requièrent pas d'objet System.Security.Policy.Evidence comme paramètre, par exemple, AppDomain.ExecuteAssembly(String, String[], Byte[], AssemblyHashAlgorithm), permettent ce scénario.

Si vous voulez utiliser un bac à sable (sandbox) pour un assembly, utilisez la surcharge AppDomain.CreateDomain(String, Evidence, AppDomainSetup, PermissionSet, StrongName[]).

Compatibilité : utilisation de l'option de stratégie CAS héritée

L'élément de configuration <NetFx40_LegacySecurityPolicy> vous permet de spécifier qu'un processus ou une bibliothèque utilise la stratégie CAS héritée. Lorsque vous activez cet élément, les surcharges de stratégie et de preuve fonctionneront comme dans les versions antérieures du Framework.

Remarque
Le comportement de la stratégie CAS est spécifié par version du runtime ; par conséquent, la modification de la stratégie CAS pour une version du runtime n'affecte pas la stratégie CAS d'une autre version.

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

Voir aussi

Tâches

Comment : exécuter du code d'un niveau de confiance partiel dans un bac à sable (sandbox)