In addition to giving you pointers and instructions on how to use custom assemblies in
reporting services, the core of this blog is to purposely detail on how to enable your report to
make use of custom assemblies that use webservices

1. Develop the custom assembly library

The details from here on forth is related to developing a .Net 2.0
assembly that calls a web service to request data from a data
repository.

To use methods from the web service inside your custom library all
you have to do is find out the web service URL and add it as a web
reference. You can then use it by fully qualifying it with a dot to
bring up the list of assessable methods. Keep in mind that the
namespace of the web service and the custom library must be the same
for intelli-sense to work.

The custom library is created was signed for improved security
however this is optional. You can sign the assembly in VS2005 by going
to the Properties -> Signing and checking on the “Sign the assembly’
checkbox.

Important
Before calling the web service in your custom assembly, you must do a
couple of things to give permission or Code Access Security (CAS)
clearance to Reporting Services to call methods within the web service
that requires access to protected resource (in my case, access to read
from an external database). Before you continue I highly recommend that
you read up on CAS at: http://msdn2.microsoft.com/en-us/library/aa902638.aspx.
I never thought I’d say this but this is actually one of the few useful
articles published by Microsoft. The following steps show you how to
get security clearance.

a. Insert the following statement just before the web service
method call to protected resource. Without this you won’t get any data
back.

System.Net.WebPermission p;
p = new System.Net.WebPermission(System.Net.NetworkAccess.Connect, URL);
p.Assert();

Where “URL” is the web address of the web service.

b. Insert the following statement to AssemblyInfo.cs file

using System.Security;

[assembly: AllowPartiallyTrustedCallers()]

The purpose of this is to enable un-trusted code (i.e. Reporting
Services) call your trusted code (i.e. your digitally signed assembly)

2. Deploy the custom assembly library

Once the DLL file is created you need to move it to a location where
Reporting services can recognize it as its own flesh and blood. There
are two locations and the one you use will depend on whether you are
deploying for Testing and Debugging or Production. The locations are:

a. Testing and Debugging
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies

b. Production
C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\bin

Warning
I do not recommend you use the “post build actions” property of your
assembly project to specify the DLL
output. Reason being is that reporting services keeps custom
assemblies loaded while it is still opened therefore any updates to the assembly will require
you to close VS. If you’re doing debugging and using the method I recommended in this blog,
the post build action method will fail

Testing is applicable when you intend to run the report locally from
SSRS Report Designer’s preview window – excluding the Debugging mode
where you step through you custom library as you run the report. For
the purpose of Testing you need not do anything more, you can proceed
straight to referencing the assembly in your report.

Deploying for Production or Debugging requires a little more work.
In this situation reporting services will need to provide proof to the
Common Language Runtime (CLR) that it has permission to execute your
custom assembly (in particular the webservice that accesses protected resource). This proof is stored in the CAS Policy configuration files – one for the Reporting Server and one for the Report Designer.

Background on Debugging:
When you run the report in debugging mode you’re actually telling the
designer to simulate the CAS policy as if it were running on the
server. The CAS policy file for the debugger is independent of the one
for the server.

To use the custom assembly in your report you need to modify the
appropriate policy configuration file to include the “Code Group”. The
best way I found to generate the Code Group is to use “Mscorcfg.msc”
(.Net Framework Configuration Tool assessable via the VS Command
Prompt). The following screens are instructions on HOW-TO.

a. Expand the Code Group Node under Machine and create a new code group

b. Give your group a name

c. Import your custom assembly – remember to select Strong Name as Condition type.

d. Grant Reporting Services full trust to the custom assembly

e. Open .NET security configuration file at:

C:\WINDOWS\Microsoft.NET\Framework\<.Net version>\CONFIG\security.config
Where “.Net version” is the framework version currently installed and used on your system

f. Do a search for the code group name you supplied earlier and copy everything between the Code Group tags. Example -

g. Now that you have the code you’re ready to paste it into
the Policy file. Like I mentioned earlier there are 2 policy files, one
for the Reporting Server and one for the Report Designer.

For Debugging, add the Code Group to:
C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\rssrvpolicy.config

For Production, add the Code Group to:
C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\rssrvpolicy.config

h. Once that’s done you’re pretty much ready to use the
assembly in your report. The stuff you just created in .Net Framework
2.0 Configuration can be deleted if need be as it does not impact on
anything.

3. Use the custom assembly library

Now comes the easy part where you should be able to do blind-folded after what you’ve just been through.

a. First you need add the assembly to your report reference list

The assembly name details may change each time you update your assembly which means you’ll have to delete and re-add it.

The Classes section is optional and depends on how you designed your
class. If your class is static or contains static methods then you need
not use it as there’s no need to create an instance of the class in
order to use it. However, if it’s the opposite then you need to supply
the class name and give it an instance name. The class name must be in
the format of namespace.classname

b. Once you’ve added the reference you can call the methods by typing either one of the following.

=Namespace.Class.Method
This is applicable if you’re calling a static member. Namespace, class and method is what’s unique to your assembly.

=Code.InstanceName.Method
This is used when you’re calling a non-static method

Reference

Bryantlikes
http://blogs.sqlxml.org/bryantlikes/pages/824.aspx

Thanks goes to Bryantlikes for writing the blog that got me started and thinking.

Pre-requisite:
You must ensure that the DLL of your assembly is copied to reporting services private assembly location (see below) otherwise your report won’t recognize it.

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies

You need to do this at least once and anytime you update the assembly code. In the case of updates you need to close VS altogether before you can copy it to the directory. Reason being is because Reporting Services only loads assemblies once and keeps it in memory for improved performance.

a. To add an existing assembly project to your reporting project just go File -> Add -> Existing Project.

b. To specify the report you want to debug go Project -> Properties

That’s really all there is to it. You can step through your code by adding breakpoints to your custom source and hitting F5. The most common problem you’ll probably run into is you forget to update the DLL to reporting services private assembly location.