What version of the CLR does Reporting Services 2012 run under?

Question

Reporting Services 2008 R2 runs under CLR 2.0. What version of the CLR does Reporting Services 2012 run under?

I think the answer is also 2.0 as I found the following in ReportingServicesService.exe.config after a new installation:

  <startup>
    <supportedRuntime version="v2.0.50727"/>
  </startup>

Can someone confirm this for me?

I'm asking because I was thinking of updating my data extension project to .NET 4.0, but won't be able to if the CLR version is still 2.0.

Thanks in advance.

Answer 1

The supportedRuntime version setting is set to v2.0.50727 even for sql server 2012. To answer your question you cannot update your data extension project to use .net version 4.0.

However you can build them using .net 3.5 and they should work with sql server 2012.

Answer 2

Where SQL 2012 is concerned, why doesn't custom code in reporting services allow .Net 4.0 yet? 

That version of the framework is fairly popular these days, and has been since the release of SQL 2012.  In fact, a lot of third-party API vendors are already deprecating their support for the previous version of the CLR.

Is it reasonable to expect that SQL 2012 will release an SP that introduces support for .Net 4.0 in SSRS?  Is it reasonable to expect that some future version of SQL will introduce support for .Net 4.0 in SSRS? 

If Microsoft has no plans to upgrade to the new CLR, we are forced to re-write our custom data processing extensions (DPE).  I'm getting the impression that these custom DPE's were a little-used feature which have apparently taken us out into the weeds.  Would it be more a more common approach to get data out of XML via web services (a built-in data connection type)?

This issue doesn't even show up in the Microsoft Connect at all .  Yet it seems like a significant problem from where we stand.

Answer 3

Judging by the lack of questions and discussions on this forum around DPEs I would indeed feel that they are a little used feature; much more commonly what it seen is calling web services... calling web services via SSIS and staging into tables and (less commonly, on a SQL level) using CLR routines in SQL server to call web services on the fly... 

I would have no expectations *whatsoever* regarding support for .NET 4.0 in SSRS in a future version, and even less expectation that it would be introduced in an SP to the current version (indeed i would expect that it is safe to assume it will NOT be introduced in a service pack to the current version).

And I would have little expectation either that you will receive any official announcements from Microsoft on this issue...

---

Thanks! Josh Ash

Answer 4

DPEs already do the work of the hypothetical web service that you mention.   They run fast and local, with nothing between them and the RDL but the interfaces defined in the API.

Correct me if I misunderstand, but your solution uses a lot of extra components.  These components seem to just move data around the network from one place (original data resource) to another (HTTP web services) to another (SSIS or SQL CLR instance) to another (SSRS reportserver).  As much pain as it hurts to be on the 2.0 CLR, I think this is still more preferable.

 

It is a shame about how SSRS is getting so far behind.  I'm not overly impressed with part of the product.  Microsoft should finish their process of taking SSRS out of SQL Server and dump it on the big, heaping pile of SharePoint.  ;)

---

David Beavon

Answer 5

They do indeed use more components than DPE's in SSRS. 

But for example, calling web services via SSIS and staging into tables is used for integration, as well as reporting, so it is a technology in use for other reasons (eg data warehousing). And there is no custom .net programming required.. 

If you go through the trouble of developing a DPE for SSRS it can only be used in SSRS. 

"It is a shame about how SSRS is getting so far behind.  I'm not overly impressed with part of the product.  Microsoft should finish their process of taking SSRS out of SQL Server and dump it on the big, heaping pile of SharePoint.  ;)"

Ha :) I hope that doesn't happen, I much prefer native SSRS. Though there hasn't been many new features in native SSRS for quite some time now. But we are working with a vendor that makes money from selling new products, not maintaining existing ones :)

---

Thanks! Josh Ash

Answer 6

Above Josh said:

"I would have no expectations *whatsoever* regarding support for .NET 4.0 in SSRS in a future version, and even less expectation that it would be introduced in an SP to the current version (indeed i would expect that it is safe to assume it will NOT be introduced in a service pack to the current version)."

... but after reading about SSRS in "integration mode" with SharePoint 2013, I suspect that Microsoft has fixed that "mode" of SSRS 2012 SP1 so that it can run with the 4.0 CLR.  Can someone confirm that SharePoint 2013 will run an RDL containing CLR-4.0-based expressions?  (I don't have SharePoint 2013 available to me yet.)  You might try using System.Numerics.BigInteger from your RDL code or something like that.

I already know that the "native mode" of SQL 2012 SP1 chokes on anything CLR-4.0-based.

---

David Beavon