Visor de informes: error en la solicitud de permiso de tipo SqlClientPermission

Question

Estoy usando el control ReportViewer de Visual Studio 2008 en modo local con objetos como fuente de datos. Mis clases se asignan a tablas de datos en mi base de datos. En los objetos, carga objetos relacionados según sea necesario. Por lo tanto, deja la referencia nula hasta que intente utilizar la propiedad, luego intenta cargarla desde la base de datos automáticamente. Las clases usan el espacio de nombres System.Data.SqlClient.

Cuando interactúo con los objetos en mi aplicación Windows Forms, todo funciona como se esperaba. Pero cuando paso el objeto para que se use como Fuente de datos de informe e intenta cargar automáticamente el objeto relacionado, falla. El código crea un objeto SqlConnection y cuando llamo a GetCommand () sobre él, se produce la siguiente excepción:

[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

He intentado buscar el error, pero todos los resultados que se muestran son para ensamblados CLR que se ejecutan en un servidor SQL o ASP.Net. Intenté agregar la siguiente llamada en mi código (como se sugiere en los resultados de búsqueda) antes de crear los objetos SqlConnection, pero aparentemente no hizo nada:

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

¿Alguna idea?

Answer 1

He encontrado la solución. Usted especifica System.Security.Policy.Evidence de la ejecución de su ensamblaje (o uno que tenga suficientes derechos) para el LocalReport para su uso durante la ejecución.

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

Answer 2

Además de la respuesta de CuppM. El método ExecuteReportInCurrentAppDomain está en desuso desde .NET4, y se debe usar LocalReport.SetBasePermissionsForSandboxAppDomain , ya que ReportViewer ahora se ejecuta siempre en el dominio de espacio aislado:

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

Ver detalles aquí .

Answer 3

En caso de que alguien se encuentre con esto como lo hice mientras buscaba este Error de Permiso. Recibí este error usando una Aplicación de formularios Windows porque el cliente había vinculado un acceso directo a mi aplicación Exe en su máquina con " \ COMPUTERNAME \ C $ \ Application.exe " en lugar de " C: \ Application.exe. " - Esto provocó la falla del System.Security.Permission debido al uso no confiable de la intranet.

Ver http://www.duelec.de/blog/?p=236 para obtener más información.

Answer 4

Una nota al pie de la respuesta de Artem arriba ...

Tuve este problema al agregar la autenticación de Windows a mi aplicación asp.net. Targeting Framework 4.5 y uso de componentes de Informes 11. Cuando permitía usuarios anónimos (en desarrollo temprano) no tuve problemas para usar ReportViewer. Tan pronto como habilitara la autenticación de Windows, obtendría " # Error " en expresiones de agrupación, o no poder ejecutar el informe en absoluto, dando la excepción mencionada anteriormente.

Pude solucionar el problema pero con una versión ligeramente modificada de lo que Artem publicó. No estoy completamente seguro de lo que hace el código que no sea un sentido general de que le permite a CAS confiar en el código de SandViewed ReportViewer. Cualquier comentario con una pequeña explicación sería apreciado.

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

Answer 5

Un pensamiento rápido, aunque este no es un error que he visto, asegúrese de que su Assert esté en el mismo método que el código que configura la fuente de datos de recursos:

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

Los Activos de Permiso no se quedan por mucho tiempo, pueden ser un problema de seguridad, por lo que es más probable que funcionen lo más cerca posible del código que los necesita.