Report Viewer - Request for the permission of type SqlClientPermission failed

Question

I am using the ReportViewer control from Visual Studio 2008 in Local Mode with objects as the data source. My classes are mapped to data tables in my database. In the objects, it loads related objects as needed. So it leaves the reference null until you try to use the property, then it tries to load it from the database automatically. The classes use the System.Data.SqlClient namespace.

When I interact with the objects in my Windows Forms application, everything works as expected. But when I pass the object to be used as a Report Data Source and it tries to automatically load the related object, it fails. The code creates a SqlConnection object and when I call GetCommand() on it, the following exception is thrown:

[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

I've tried searching for the error, but all the results that show up are for CLR assemblies running on a SQL Server or ASP.Net. I've tried adding the following call in my code (as suggested in the search results) before creating the SqlConnection objects, but it didn't apparently do anything:

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

Any ideas?

Answer 1

In addition to the answer of CuppM. The ExecuteReportInCurrentAppDomain method is deprecated since .NET4, and LocalReport.SetBasePermissionsForSandboxAppDomain should be used instead, as ReportViewer is now always executed in sandboxed domain:

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

See details here.

Answer 2

I've found the solution. You specify System.Security.Policy.Evidence of you executing assembly (or one that has sufficient rights) to the LocalReport for use during execution.

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

Answer 3

Just in case someone stumbles upon this like I did while searching for this Permission-Error. I got this error using a Windows-Forms-Application because the customer had linked a shortcut to my Application-Exe on his machine with "\COMPUTERNAME\C$\Application.exe" instead of "C:\Application.exe." - This caused the failure of the System.Security.Permission because of the untrusted intranet use.

See http://www.duelec.de/blog/?p=236 for more Information.

Answer 4

A footnote to Artem's answer above...

I had this problem when adding Windows Authentication to my asp.net app. Targeting Framework 4.5 and using Reporting components 11. When I was allowing anonymous users (in early dev) I had no problems using the ReportViewer. As soon as I enabled Windows auth I would either get "#Error" on Grouping expressions, or not be able to run the report at all, giving the exception listed above.

I was able to work around the problem but with a slightly modified version of what Artem posted. I am not completely sure what the code does other than a general sense that it allows CAS to trust the sandboxed ReportViewer code. Any comments with a little explanation would be appreciated.

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

Answer 5

One quick thought, although this isn't an error I've seen, make sure that your Assert is in the same method as the code that is setting the resource data source:

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

Permission Asserts don't hang around for long, they can be a security issue, so doing them as near as possible to the code that needs them is most likely to work.