The definition of the report 'Main Report' is invalid.Microsoft.ReportingServices.ReportProcessing.ReportProcessingException:An unexpected error occurred in Report Processing.System.UnauthorizedAccessException: Access to the path 'C:\Documents and Settings\\Local Settings\Temp\expression_host_05cd5e1af4624646bc2dd846b60460f0.dll' is denied.
What is this expression_host_....dll file and Why is The Report Rendering Engine Trying to Access It?
When you write an expression in your report definition (any expression even something that looks like =Fields!FirstName.Value + " " + Fields!LastName.Value) or when you use Custom Code, the report rendering engine does two things; it seems to me. One the rendering engine extracts all custom expressions and custom code and, based on these custom expressions and code, it dynamically creates VB.NET classes which are then compiled on the fly to a .NET assembly. These files and the resulting assembly are placed in the %TEMP% directory; they are deleted once they are no longer needed by the current instance of the running report. The second thing the rendering engine does is referencing the dynamically created assembly (which is named expression_host_
How is The Above Explanation Related to The Error In Question?
Some anti-malware/anti-virus software do not like programs creating dynamic DLLs, it seems. In my case I verified that the dynamically created assembly was indeed blocked by the anti-malware program so that the ReportViewer and the hosting application could not use it and the even rendering engine program could not delete the expression_host dll file; which it normally does once the report is done rendering.
As soon as stopped the anti-malware program or just told to trust certain pattern of files, the report rendered perfectly without a problem.
Finally, it's worth mentioning that this problem was sporadic and had no predictable pattern. That is, one out 20 trials the report would render fine but most of the time it fails. Something which leads to believe that there was a "race" between the report rendering engine and its application and the anti-malware program. Sometimes the anti-malware program would miss the host_expression dll and the report would render fine but most of the time the dll files is blocked.
The Bottom Line:
If you're running a program that use a RLDC report in local mode and the report uses expressions and custom code, rendering the report could fail due to an anti-virus/ anti-malware program blocking the custom assembly created to host your expressions and/or custom code.
Just right had the same problem. Thank you very much for your solution.
ReplyDeleteThanks for the tip. It saved a week of struggle. Can you tell me which AV you are using? Mine is COMODO.
ReplyDeleteYou saved me!!
ReplyDeleteI was wasting days trying to solve this problem ...
My malware was bytefence.
This appears to have fixed my issue as well. IS there any other way other then excluding files to be scanned? I"m not sure if my security group will allow this
ReplyDeleteDid you find a resolution without having to address virus/firewall protection as well? My company has ours locked very tight and there's no way they're going to allow a dynamically generated library to be allowed.
Deletein my web application, i have a function to download RDLC report. if I run this function from two different tabs/browsers and run them concurently then only I get this problem, which means there is a race condition i.e. the rdlc file is in use by one user/browser/tab and at that time other user/browser/tab gets the above error message. How do I solve this?
ReplyDeleteMy application is ASP.net Core 2.0 and using public Async method/api to generate report.
I had the same problem and one of the service running on my system is blocking the rdl file. I used PM tool to make sure which service is blocking and it worked for me. Thanks for sharing the article.
ReplyDeleteJust letting you know that in 2023 this is still relevant and helping people. Running our application on .NET Framework 4.7.2.
ReplyDeleteSame problem here... still in 2023 this is a thing.
ReplyDelete