It's common to want to embed custom code within reports in Reporting Services. One thing I don't like is the inclusion of anything that looks like business logic directly in the reports. However, formatting functions, etc. seem totally appropriate.
If I want to embed custom code within Reporting Services though, I currently have two options. One is to embed the code in the report, the other is to reference an assembly. Each of these has drawbacks.
If I embed the code in a report (say just some formatting functions), I have to edit every report if I ever change that code.
The answer has been to use an assembly instead. The downside of placing code in an assembly is that I now have a deployment issue. It's very easy to deploy an RDL report file but quite another thing to deploy a .NET assembly that is referenced by it.
What I’d really like to see is an in-between option. I think a good solution would be to allow me to have another node in Solution Explorer, called something like “Shared Code” or some similar name. I could then have sets of code that I might want embedded in various reports. Then in the properties of a report, I could just specify that which of these pieces of code I'd like to have included (and embedded) in the report.
This would give me the benefit of only a single place to need to write/update the code but no downside on deployment as the code would simply be embedded in the RDL files.
I'd love to hear your thoughts on this. If you like it (or even if you don't), the Connect item is here: https://connect.microsoft.com/SQLServer/feedback/details/534679/reporting-services-should-support-include-files-via-code-inclusions
This concept makes a report very much like a server side page, like a .aspx page for example. In .NET structure as we have a .aspx page and code behind file, this concept looks similar to that. Also having this code in raw format means it would not be compiled but interpreted by the service at runtime and this opens a scope for performance issues. In my viewpoint, assembly is still the better way compared to what you propose, but I agree that a better way of developing and/or deploying the same should be facilitated from BIDS / Report Manager.
Regards,
Siddharth Mehta
Hi Siddharth,
It doesn't change the performance characteristics as you can already do this via the "Code" properties of a report. The difference is in managing those code areas.
Regards,
Greg
The only issue with that solution is that whenever you changed the code, you would need to know which of the reports is using it so that you can redeploy them all.
Of course, the advantage of only having to maintain it in one place would almost certainly outweigh this, but having some way to determine which reports are dependent on a piece of 'shared code' would be a useful extension to your idea.
I'm hoping the reports that depend on it would be the ones in the same project !
Regards,
Greg
There are probably implementation issues here.
Essentially what you are asking for is the ability to deploy an assembly by simply uploading the code for it, as presumably that code would then be compiled into an assembly. So now the question becomes, have you just evaded all the security and permission constraints that we (rightly) put on the execution and installation of a deployed assembly?
There are also issues like, "Is a shared variable in the global code shared by all the reports, or do we end up with a second copy of the assembly and whatever memory it demands for each report execution?"
In general, I'm ok with the idea, but I don't place it in it nearly as much value as things like being able to define styles that can be applied to report objects much like a style in HTML (css) or even MS Word. And a global storage space for such styles would be even more useful.