8

Preface:

Development Environment: Visual Studio 2010 with BIDS + MSSQL 2012 on local box

Production Environment: MSSQL 2008 R2 For Live Report Server

I am having a problem with deploying a report when referencing System.Core in my report. The error is below.

Error while loading code module: ‘System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’. Details: Could not load file or assembly 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

I am referencing the System.Core in my report so that I can use the TimeZoneInfo class. I've seen other questions asked about using this class in SSRS and I've not been able to resolve the issue following any of the advice in those questions.

REF

Working with Time Zones in SSRS

SSRS 2k8, custom dll, file not found

Reporting Services 2012 deploy error: "Error while loading code module"

I can reference the System.Core 4.0 and run locally without any issue; however, when I deploy, I get the above error message. To clarify further.. this happens DURING the deploy process, not after deploying and attempting to run the report on the server.

EDIT

The report RDL xml for CodeModules looks like this: 

<CodeModules>
<CodeModule>System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

That's about as much "Embedding" as I can tell that it does. It really is just a ref to the assembly from the looks of it.

Assistance would be greatly appreciated.

SOLUTION Since you can't reference 4.0, you can reference 3.5 to gain access to the TimeZoneInfo class.

Step 1. Create a wrapper class for the TimeZoneInfo logic you wish to employ

Step 2. Target 3.5

Step 3. Build a release version and copy it to your [DRIVE]:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies directory so that your designer can load it

Step 4. Deploy the same assembly to the SQL Server @ the following folder [DRIVE]:\Program Files\Microsoft SQL Server\MSRS10.SQL2008\Reporting Services\ReportServer\bin\

Now you can deploy your report. So my errors were the following

  1. I didn't reference 3.5

  2. I didn't copy to the proper directory for my visual studio instance to pick up the assembly. I had moved my install to a different directory and I didn't put it in the new path.

UPDATE If anyone is trying to ref .NET 4.0 ins SSRS 2012 and above and still gets an error, the answer is simple. SSRS 2012 and 2014(?) STILL do not support .NET 4.0

source

This one seems to suggest that SSRS 2014 doesn't support it either (I am speechless, MICROSOFT!) MS KB

Community
  • 1
  • 1
Hardrada
  • 728
  • 8
  • 19
  • Have you tried placing the version of the assembly you are using so that the report designer has access to it. It could be that the deployment process is doing a version check using ..\Visual Studio 8\Common7\IDE\PrivateAssemblies folder and not the report server folder. I am certain this is where SSRS looks for embedded assemblies at design time. This is probably a warning and not an error. – Ross Bush Mar 07 '13 at 01:50
  • The assembly is System.Core which is in the GAC. This is why I'm so confused. If it's in the GAC, why isn't it being "picked up" ? – Hardrada Mar 07 '13 at 03:18
  • Since the report rendering and processing does not rely on .NET the same way web/form apps do I guess SSRS treats any embedded assembly in a .rdl as a custom assembly. – Ross Bush Mar 07 '13 at 14:46
  • I updated my post to include what the RDL has "embedded" as far as a reference goes. – Hardrada Mar 07 '13 at 16:12
  • Version=4.0.0.0 <-- I don't think you can reference the 4.0 assembly version. Do you have a 2.0.0.0 version of Core installed? – Ross Bush Mar 07 '13 at 16:27
  • The whole point is to use the TimeZoneInfo class which is not in 2.0. So what you're saying is that 2008 r2 report server doesn't use 4.0? or can't even reference it either by a straight reference in the report or by following the "custom module" paradigm, i.e. using System.Core from 4.0 as a custom assembly? – Hardrada Mar 07 '13 at 17:05
  • 1
    I am afraid so. I did a quick test with a 4.0.0.0 assembly and received the same error. The 2.0.0.0 version of the assembly worked fine. If your target server has 4.0 installed then maybe you could create your own assembly and reference the 4.0 System. Core wrapping what you need. – Ross Bush Mar 07 '13 at 18:06
  • I did try that recently and I couldn't even get the designer to recognize my referenced wrapper assembly. I put in a support ticket to microsoft. I will report solutions if any. – Hardrada Mar 07 '13 at 19:12
  • 1
    steps detailing where to place the code modules on the local and remote server are invaluable tips. – MikeJ Dec 17 '14 at 18:47
  • just as a side note if you are going to reference an assembly that is different than the version installed on a machine or registered in the GAC, you will need to ensure the reference on the proj file is not version specific. Also, you can open the project file in notepad and remove the public token so that reference is not as strict. – Mike Jun 19 '15 at 12:09
  • Hardrada - please can you put your solution as the Answer to your question, rather than in the question itself. This prevents the question from appearing in lists of unanswered questions. Thanks. – Nathan Griffiths Jun 24 '15 at 22:58
  • Not a problem.. done – Hardrada Jun 29 '15 at 14:33

1 Answers1

0

As requested:

SOLUTION

Since you can't reference 4.0, you can reference 3.5 to gain access to the TimeZoneInfo class.

Step 1. Create a wrapper class for the TimeZoneInfo logic you wish to employ

Step 2. Target 3.5

Step 3. Build a release version and copy it to your [DRIVE]:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies directory so that your designer can load it

Step 4. Deploy the same assembly to the SQL Server @ the following folder [DRIVE]:\Program Files\Microsoft SQL Server\MSRS10.SQL2008\Reporting Services\ReportServer\bin\

Now you can deploy your report. So my errors were the following

I didn't reference 3.5

I didn't copy to the proper directory for my visual studio instance to pick up the assembly. I had moved my install to a different directory and I didn't put it in the new path.

Hardrada
  • 728
  • 8
  • 19