Report Viewer - La demande d'autorisation de type SqlClientPermission a échoué

Question

J'utilise le contrôle ReportViewer de Visual Studio 2008 en mode local avec des objets comme source de données. Mes classes sont mappées aux tables de données de ma base de données. Dans les objets, il charge les objets associés en fonction des besoins. Donc, il laisse la référence null jusqu'à ce que vous essayiez d'utiliser la propriété, puis il essaie de le charger automatiquement à partir de la base de données. Les classes utilisent l'espace de noms System.Data.SqlClient.

Lorsque j'interagis avec les objets de mon application Windows Forms, tout fonctionne comme prévu. Mais lorsque je passe l'objet à utiliser en tant que source de données de rapport et qu'il tente de charger automatiquement l'objet associé, il échoue. Le code crée un objet SqlConnection et lorsque j'appelle GetCommand () dessus, l'exception suivante est levée:

[System.Security.SecurityException] {
"Request for the permission of type 'System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."
} System.Security.SecurityException

J'ai essayé de rechercher l'erreur, mais tous les résultats affichés concernent des assemblys CLR s'exécutant sur un serveur SQL ou ASP.Net. J'ai essayé d'ajouter l'appel suivant dans mon code (comme suggéré dans les résultats de la recherche) avant de créer les objets SqlConnection, mais il n'a apparemment rien fait:

System.Data.SqlClient.SqlClientPermission(System.Security.Permissions.PermissionState.Unrestricted).Assert();

Des idées?

Answer 1

J'ai trouvé la solution. Vous spécifiez System.Security.Policy.Evidence de l'exécution de l'assembly (ou de celui qui dispose de droits suffisants) sur LocalReport pour une utilisation pendant l'exécution.

reportViewer.LocalReport.ExecuteReportInCurrentAppDomain(System.Reflection.Assembly.GetExecutingAssembly().Evidence);

Answer 2

En plus de la réponse de CuppM. La méthode ExecuteReportInCurrentAppDomain est obsolète depuis .NET4 et LocalReport.SetBasePermissionsForSandboxAppDomain étant donné que ReportViewer est désormais toujours exécuté dans le domaine en bac à sable: / p>

PermissionSet permissions = new PermissionSet(PermissionState.None);
permissions.AddPermission(new FileIOPermission(PermissionState.Unrestricted));
permissions.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
ReportViewer1.LocalReport.SetBasePermissionsForSandboxAppDomain(permissions);

Voir les détails ici .

Answer 3

Juste au cas où quelqu'un trébucherait comme je l'avais fait en cherchant cette Permission-Error. Ce message d'erreur s'affiche à l'aide d'une application Windows-Forms , car le client a associé un raccourci à mon application-Exe sur sa machine avec "\ COMPUTERNAME \ C $ \ Application.exe". au lieu de " C: \ Application.exe. " - Cela a entraîné l'échec de System.Security.Permission en raison d'une utilisation intranet non fiable.

Voir http://www.duelec.de/blog/?p=236 pour plus d'informations.

Answer 4

Une note de bas de page à la réponse d'Artem ci-dessus ...

J'ai eu ce problème lors de l'ajout de l'authentification Windows à mon application asp.net. Targeting Framework 4.5 et utilisation des composants de création de rapports 11. Lorsque j'autorisais les utilisateurs anonymes (au début du développement), je n'avais aucun problème à utiliser ReportViewer. Dès que j'activerais l'authentification Windows, j'obtiendrais soit "# Erreur". sur les expressions de regroupement ou ne pas être en mesure d'exécuter le rapport, en générant l'exception indiquée ci-dessus.

J'ai pu contourner le problème, mais avec une version légèrement modifiée de celle publiée par Artem. Je ne suis pas tout à fait sûr de ce que le code fait si ce n’est le sens général qui permet à CAS de faire confiance au code ReportViewer en bac à sable. Tous les commentaires avec une petite explication seraient appréciés.

    Dim permissions As PermissionSet = New PermissionSet(PermissionState.Unrestricted)
    myReportViewer.LocalReport.SetBasePermissionsForSandboxAppDomain(permissions)

Answer 5

Une idée rapide, bien que ce ne soit pas une erreur que j'ai vue, assurez-vous que votre assertion est dans la même méthode que le code qui définit la source de données de la ressource:

System.Data.SqlClient.SqlClientPermission mPermission = new SqlClientPermission(System.Security.Permissions.PermissionState.Unrestricted);
try
{
    mPermission.Assert();
    //rest of your code
}
//Handle Exceptions

Les assertions de permission ne traînent pas longtemps, elles peuvent constituer un problème de sécurité. Par conséquent, si elles sont aussi proches que possible du code qui en a besoin, cela fonctionnera probablement.