Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SSRS Custom Assemblies could not be loaded under Visual Studio 2017

I have just installed VS 2017 and moved my SSRS project from VS 2015 to 2017. I have a custom assembly which is working fine under VS 2015, but not 2017. It says

Error while loading code module: 'CustomLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Details: Could not load file or assembly 'CustomLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

I had exact same problem under VS 2015 and the solution was moving my custom dll under

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies

So, I have moved my custom dll under

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PrivateAssemblies

which I believe is the correct path for VS 2017 and check file/folder permissions and set them identical, but no way, it still throws same error.

What am I missing?

like image 487
bsaglamtimur Avatar asked Apr 20 '17 13:04

bsaglamtimur


3 Answers

This now requires two locations for the dll - the first works for new VS2017 RS projects, but upgraded projects also need the dll in the second location:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\SSRS 

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PrivateAssemblies
like image 123
Matt Frend Avatar answered Nov 20 '22 14:11

Matt Frend


I too have run into this issue, what fixed it for me was doing what was mentioned above and also editing the RSPreviewPolicy.config located in

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsof‌​t\SSRS

I set PermissionSetName="FullTrust" in all of the < CodeGroup>< /CodeGroup> blocks.

like image 33
Ross Degrand Avatar answered Nov 20 '22 14:11

Ross Degrand


TLDR - C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\SSDTRS

I was having the same problem - try using the Fusion Assembly Binding Log Viewer to peer into what the problem is as per http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx

With "Log bind failures to disk" enabled (and restarting VS) the devenv.exe process folder in your log location should then produce log files when you recreate the problem. Part of what it will tell you is the various folder locations VS is checking for assemblies. My issue was that I hadn't copied a required assembly. You might also be having a problem with it not liking a specific version of a dll it is trying to load (for instance .Net 4 v 2), the logs will highlight that as well.

The viewer tool is pretty poor in terms of being able to sort columns. I found it much easier to just open C:\FusionLogs\Default\devenv.exe (where I had set C:\FusionLogs as the custom log path), sort by date modified and watch as new files were created when trying to add the data source.

In terms of which folder to use - I initially dropped them into PrivateAssemblies which worked for creating the data source / reports. However when it came to build the preview the report I then got another could not load assemblies message. Again using the log viewer, but this time in the PreviewProcessingService.exe folder the error suggests the only directory that checks for the assemblies is: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\SSDTRS - this location works for both creating and previewing reports.

like image 43
Chris Avatar answered Nov 20 '22 14:11

Chris