WiseOwl Training - Established 1992 Wise Owl Training

Established May 1992
30 years in business
Wise Owl Training
30 years in business
See 482 reviews for our classroom and online training
SSRS custom assemblies using C# or VB
Part six of a six-part series of blogs

Reporting Services allows you to write functions in C# or Visual Basic, then reference these as custom assemblies. This blog shows how - and why - you might do this.

  1. Creating Custom Assemblies in Reporting Services
  2. Creating a Project, Class and Function in VB or C#
  3. Create and Deploy the Code DLL
  4. Referencing and Using Custom Assemblies in Reports
  5. Post-Build Events to Help Deployment
  6. Debugging Custom Assemblies (this blog)

Posted by Andy Brown on 03 August 2012

You need a minimum screen resolution of about 700 pixels width to see our blogs. This is because they contain diagrams and tables which would not be viewable easily on a mobile phone or small laptop. Please use a larger tablet, notebook or desktop computer, or change your screen resolution settings.

Debugging Custom Assemblies

One of the great advantages of custom assemblies over embedded code is that you can debug them, but there are a fair few hoops to jump through.  Take a deep breath, and read on!

Set a Project Dependency

The first thing to do is to tell your report server project that it depends on the class library:

Solution properties

Right-click on your solution (not a project) and choose to change its properties. This is one of the few times you'll ever see this dialog box.


Now establish the correct dependencies:

Creating project dependencies

To create dependencies:


You can get debugging to work without having your report and class library projects in the same solution, but why make life difficult?

Setting BreakPoints

To set a breakpoint next to a line of code:

Setting code breakpoint

Either click in the margin to the left of a line of code (as shown here), or click in the line and press the F9 key.


When you debug your project, code execution will stop at any line for which you've set a breakpoint, and you'll be able to debug your code.

Building and Deploying your Class Library

As always, you need to build your class library to make it available to SSRS:

Building class library

Right-click on your class library project and choose to build it.


You now need to copy the DLL file for the class library into the folder Visual Studio uses when previewing a report, as explained earlier in this blog series.  On my laptop, this involves copying the DLL from this folder:

C:\ajb files\Manual\FunctionsC\bin\Debug

to this one:

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

Setting a Start-Up Project and Report

You now need to check that when you debug, you will go to the correct project and report.  First set the start-up project:

Setting the startup project

In this case, this step is unnecessary: the project was already shown in bold, so it must already have been the default start-up project.


Now display the properties of the project:

Display project properties

Right-click on the project to display its properties.


You can now specify which report will first appear when you debug your project:

Setting startitem report

Choose the report which should first appear when you debug your project.

Check you're Debugging Locally

You now want to check that when you eventually debug, SSRS will do this on the local (development) copy of SSRS, without deploying files to the production server.  Choose to manage your build configuration:

Managing build configuration

There are several ways to get to this - one is shown here.

Now make sure that Visual Studio doesn't deploy your reports when you choose to debug:

Changing debug configuration

Choose to debug locally, then tell Visual Studio not to deploy your reports when you debug.

Debugging your Report

Hallelujah!  You're now ready to debug your report:

Debugging report

Click on the tool shown or press F5 to debug.

SSRS should now allow you to step through your code from the first breakpoint that it finds onwards:

Breakpoint hit

Code execution stops at the first breakpoint found. You can now use any of the standard Visual Studio debugging keys to debug (see below for some ideas).


Debugging is a big subject, but here are some things to try:

  • Press F11 to step through code line by line.
  • Hover your mouse over any variable or property to see its value.
  • Right-click on any line to make it the next executable statement, or click and drag on the yellow arrow to the right of a line of code to change the next executable statement.

When you've finished debugging, press F5 to resume code execution (it might be an idea to remove any breakpoints first). 

You can remove a breakpoint in the same way as you created it - press F9 or click on the line's left margin.

Alternatively, just close the report preview window to stop debugging.

That's it, folks!

And that - I'm pleased to say - is the end of this long exploration of custom assemblies.  The only thing that I was intending to cover that I've missed out is how to create and use named instances of classes, but I can't see why you'd ever want to do this.  Let me know if you think otherwise!

This blog has 0 threads Add post