Средство просмотра отчетов - Сбой запроса разрешения типа SqlClientPermission

Question

Я использую элемент управления ReportViewer из Visual Studio 2008 в локальном режиме с объектами в качестве источника данных. Мои классы сопоставлены с таблицами данных в моей базе данных. В объектах он загружает связанные объекты по мере необходимости. Таким образом, он оставляет ссылку на ноль до тех пор, пока вы не попытаетесь использовать свойство, а затем попытается автоматически загрузить его из базы данных. Классы используют пространство имен System.Data.SqlClient.

Когда я взаимодействую с объектами в приложении Windows Forms, все работает как положено. Но когда я передаю объект для использования в качестве источника данных отчета, и он пытается автоматически загрузить связанный объект, происходит сбой. Код создает объект SqlConnection, и когда я вызываю GetCommand () для него, выдается следующее исключение:

[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

Я попытался найти ошибку, но все результаты отображаются для сборок CLR, работающих на SQL Server или ASP.Net. Я пытался добавить следующий вызов в мой код (как это было предложено в результатах поиска) перед созданием объектов SqlConnection, но он, очевидно, ничего не делал:

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

Есть идеи?

Answer 1

Я нашел решение. Вы указываете System.Security.Policy.Evidence о том, что вы выполняете сборку (или ту, которая имеет достаточные права) для LocalReport для использования во время выполнения.

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

Answer 2

В дополнение к ответу CuppM. Метод ExecuteReportInCurrentAppDomain устарел начиная с .NET4, и вместо него следует использовать LocalReport.SetBasePermissionsForSandboxAppDomain , так как ReportViewer теперь всегда выполняется в изолированном домене:

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

Подробнее здесь .

Answer 3

На тот случай, если кто-то наткнется на это, как я, когда искал эту ошибку разрешения. Я получил эту ошибку с помощью Windows-Forms-Application , поскольку клиент связал ярлык с моим Application-Exe на своем компьютере с помощью команды \ COMPUTERNAME \ C $ \ Application.exe " вместо " C: \ Application.exe. " - Это вызвало сбой System.Security.Permission из-за ненадежного использования в интрасети.

См. http://www.duelec.de/blog/?p=236 для получения дополнительной информации.

Answer 4

Сноска на ответ Артема выше ...

У меня была эта проблема при добавлении аутентификации Windows в мое приложение asp.net. Targeting Framework 4.5 и использование компонентов Reporting 11. Когда я разрешал анонимным пользователям (в начале разработки), у меня не было проблем с использованием ReportViewer. Как только я включил аутентификацию Windows, я либо получу " # Ошибка " Группировка выражений, или не сможет запустить отчет вообще, с исключением, перечисленным выше.

Мне удалось обойти проблему, но с немного измененной версией того, что опубликовал Артем. Я не совсем уверен, что делает код, кроме общего ощущения, что он позволяет CAS доверять изолированному программному обеспечению ReportViewer. Любые комментарии с небольшим объяснением будут оценены.

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

Answer 5

Одна быстрая мысль, хотя это не ошибка, которую я видел, убедитесь, что ваш Assert использует тот же метод, что и код, который устанавливает источник данных ресурса:

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

Заявления о разрешениях не задерживаются надолго, они могут быть проблемой безопасности, поэтому наиболее вероятно сработает их как можно ближе к коду, который нуждается в них.