Teun.ToString()

by Teun Duynstee [Macaw]

<December 2008>
SuMoTuWeThFrSa
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910


Navigation

Subscriptions

News

I discontinued this blog. I now post at: www.TeunToString.net



Download Finch PocketBlogger

Post Categories

Article Categories



Tuesday, June 14, 2005 - Posts

Setting CAS to use our Reporting Services data extension

This post refers to my article on reporting with Reporting Services over WSS Lists.

The extension presented in the article works fine in the Report Designer in Visual Studio, but it turns out that deploying it to the server requires some extra work. A problem you will encounter is that when you try to access your report through the Reporting Services website, it will give you an error like this:

Reporting Services Error

  • An error has occurred during report processing. (rsProcessingAborted) Get Online Help
    • Query execution failed for data set 'dataset_name'. (rsErrorExecutingCommand) Get Online Help
      • Request for the permission of type System.Net.WebPermission, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.

The problem here is that the Reporting Services engine does not trust our extension code. For more on Code Access Security in .NET, check out this MSDN article. We can tell it to trust our dll by editing the file rssrvpolicy.config that you will find in the C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer directory. It contains XML defining a number of CodeGroups and their corresponding trust levels. We just add this code snippet at the end of the list of CodeGroups:

Note that we specifiy our exact dll to be trusted. For new extensions you may add, you'll have to add these to the list of CodeGroups as well.

The FullTrust level is rather crude of course. You could define another named permission set that has exactly the required permissions for this extension (network access).

Also: I chose to specify which code to trust using the file location (UrlMembershipCondition). Some people say you'd better sign your assembly with a strong name and trust the strong name (StrongNameMembershipCondition). I am not a very big fan of strong naming and I would suggest resorting to this way only if you really need it. After all: people who can replace your dll in the bin directory can probably also tamper with the rssrvpolicy.config file. More on what's wrong with strong naming.

posted Tuesday, June 14, 2005 12:34 PM by TeunD with 1 Comments




Powered by Dot Net Junkies, by Telligent Systems