MS Report Viewer errors using Microsoft.Web.RedisSessionStateProvider & Azure Redis Cache RRS feed

  • Question

  • Can Microsoft ReportViewer, be configured to work correctly using AsyncRendering = true, when using Microsoft.Web.RedisSessionProvider and an Azure Redis Cache? If so, how?

    My app runs fine when using the standard default InProc session state provider. But when I converted it to use the redis session state cache, I get this error:

    An error occurred during local report processing. An error has occurred during report processing. Cannot create a data reader for dataset 'DataSet1'.

    I suspect it could be a serialization related issue, maybe the ReportViewer is storing data in the sessionstate that doesn't work right with a redis sessionstate cache. But I don't know how to determine for sure that is the problem, or how to solve it.

    I can make it work with AsyncRendering = false, but that doesn't give a desirable user experience when a long report is running, so I'd like to make it work with AsyncRendering = true.

    I have been searching for posts for others with this experience, but I have found none. I have checked my web.config configuration for the SessionStateProvider - it seems correct, and appears to be working correctly, because my app behaves correctly as far as basic sessionstate operations because when my session hops from one Scale Out instance to another, the other data we store in sessionstate is working as expected. So I don't think it is the redis cache, or the redis session state provider per se, but perhaps an incompatibility between Microsoft ReportViewer (15) and the redis session state provider+Azure cache.

    Any tips for diagnosing this further, or getting it to work appreciated!

    Monday, August 19, 2019 5:40 PM

All replies

  • Hi BoAlex,

    Another thread you can reference that is related is: Redis cache, RedisSessionStateProvider, MS ReportViewer == performance problems (link). They could never get  AsyncRendering = true to work correctly. 

    I do want to ensure that you have the following installed: ASP.NET Output Cache Provider for Azure Cache for Redis (link). Please see the section About RedisSerializerType (link).

    Linking Stack Overflow post regarding the same topic (link)



    Tuesday, August 20, 2019 1:16 AM
  • Hi Mike,

    Thanks for the response!  Yeah, I was part of that thread in 2018, heck, it was long enough ago I forgot about it!

    I see that mek7 wrote "The ReportViewer itself is a very buggy, legacy and unsupported component, as it seems." - if it's true that it is unsupported, that is unfortunate.  I have inherited a legacy ASP.NET webforms app that makes extensive use of ReportViewer, and though we may eventually replace it with some other report technology, it will be a lot of work and take time.  We had hoped to make a simple port from a hosted bare metal machine running IIS to Azure App Services, and use scaling for more efficient operations, but a few issues like this  apparent ReportViewer/RedisSessionStateProvider problem are making it more effort/time/money than we had hoped.

    I have considered simply NOT using RedisSessionStateProvider for my scaled OUT deployment, and simply leaving AAR Affinity ON, and we may resort to that.  But still trying to see if we can get the RedisSessionStateProvider to work for best Azure App Service scale out/in operations, load balancing, etc.

    I will go re-read your suggestions about ASP.NET Output Cache Provider Cache for Redis - though I do not quite understand how that fits into my situation.  Can you briefly explain how that relates to the RedisSessionStateProvider?  Does adding the Output Cache affect RedisSessionStateProvider operations as well?

    My legacy app is too large and proprietary to post the code to demonstrate the problem, so I am working on a smaller bug demonstration app to share here, and other places I have posted - but it will take some time to build the demo app up enough to demonstrate the problem.  My simple version with tiny report didn't exhibit the problem, so I have to keep adding the parts my real legacy app has till the bug appears, then I'll post it.

    Thanks again for your assistance - getting any tips or suggestions is great!


    Tuesday, August 20, 2019 11:19 AM
  • Mike,

    A little more clarification on my question about ASP.NET Output Cache Provider Cache for Redis - after reading the linked article you sent, it seems that is used when you explicitly modify pages to cache their output - to optimize page requests by using the cache instead of re-rendering the pages.  I can understand that improving efficiency - but that is configured by modifying pages with:

    Output cache directive

    Add an OutputCache directive to each page for which you wish to cache the output.

    XML<button aria-label="Copy code" class="action" data-bi-name="copy" style="box-sizing:inherit;font-family:inherit;font-size:12.8px;margin:0px;cursor:pointer;padding-padding-right:10px;padding-display:flex;align-items:center;">Copy</button>
    " style="box-sizing:inherit;font-family:SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace;font-size:1em;direction:ltr;border:0px;padding:0px;display:block;line-height:19px;"><%@ OutputCache Duration="60" VaryByParam="*" %>

    In the previous example, the cached page data remains in the cache for 60 seconds, and a different version of the page is cached for each parameter combination. For more information about the OutputCache directive, see OutputCache .

    Once these steps are performed, your application is configured to use the Redis Output Cache Provider.

    My pages are not using an OutputCache (that I know of, I will go look), so I'm not sure how the Output Cache relates to ReportViewer.  My situation is ReportViewer seems to be choking on my SessionState being configured for Redis when AsyncRendering = true.  Are you thinking that ReportViewer would behave differently (better?) because perhaps it uses Redis Output Cache Provider under the covers?

    Thanks again,


    Tuesday, August 20, 2019 11:32 AM
  • Thank you for the additional details, Bo. Yes, the idea is that you are using Redis for SessionState and OutputCache. Otherwise, you are having to pull data from the database tables. 

    I have a question out to the product group on this for more clarity as there is no clear information on leveraging Report Viewer control specifically with Redis but, there is the following sample: ASP.NET Session State and Output Caching (link).

    I will update you when I have additional information from the product group but please do take a look at this sample.



    Wednesday, August 21, 2019 12:16 AM
  • Hello Mike,

    I still don't quite have a standlone code project to demonstrate my problem, though I have clarified the conditions of the problem more and am getting closer.

    After reviewing all of my reports that work, or don't work in my deployment with RedisSessionStateProvider, I found that the ONLY ones I have am having problems with are the ones on pages that have more than one ReportViewer on them.  One ReportViewer on one Page, works, even with RedisSessionStateProvider.

    But with >1 ReportViewer on a Page, And it doesn't matter if I use AsyncRendering="true" or AsyncRendering="false", these ReportViewers fail, though in slightly different ways.

    - In all cases, the "first" ReportViewer on the page that is "loaded" with it's DataSet, seems to be ok.  But subsequent ReportViewers will get an error on the DataSet.
    - In AsyncRendering="true" mode, the ReportViewers after the first get the error immediately - not even the first page is rendered correctly.
    - In AsyncRendering="false" mode, the ReportViewers after the first render the first page correctly, but any page changes on ANY of the N instances of the ReportViewer cause the 2nd ReportViewer on up to get the DataSet error.

    - I tried creating different DataSet objects for each report - no difference.

    - I tried naming the DataSets different for each report (DataSet1, DataSet2, DataSet3...) no difference.

    Yes, I could re-write these reports to be one page, one report, but a) it's a lot of work and b) it changes the user experience quite a bit, proliferates a lot more pages when currently the N reports are based on the same data selections by the user and are just different formatting for the same data - don't really want to do this.

    We've considered switching to other SessionState providers (Table, SQL, etc.), but these are reportedly slower, or not really supported, compared with RedisSessionStateProvider.

    so to me, right now, the question is why can't multiple ReportViewers be used at the same time on a page when using the RedisSessionStateProvider?  Perhaps the ReportViewer tries to cache things that are not serializable?  Or too big?  Or name collisions in the cache?

    I am continuing my experimentation, and will try the OutputCache you suggested, but I don't really anticipate this working since we don't use ANY output caching now, and our report data is dynamic, so it's hard for me to understand how caching page output is going to work at all, let alone help the ReportViewers that are having the problem.

    I can give up on OutProc SessionState, and just use AARAffinity ON, but this seems to be a weak solution, leaving me with sticky sessions and less than optimal scalability on Azure - so why?  (yeah, I'm a little frustrated...)

    More as my experimentation evolves...

    Sunday, August 25, 2019 3:02 PM
  • Mike,

    I have continued to get closer to the problem.  I will summarize my problem case:

    - More than 1 ReportViewer on the same page
    - AsyncRendering="true"
    - RedisSessionStateProvider
    - OutputCache does not help Async mode to work.

    I CAN get multiple ReportViewers to work in Sync mode - and OutputCache does not seem to be necessary for this to work correctly.

    I have a standalone program that demonstrates the report working correctly in Sync mode, and incorrectly in Async mode - seems like a lot to post here in the message - how can I send you the solution/project so you can see for yourself?



    Wednesday, August 28, 2019 4:15 PM
  • Hi Bo,

    Thank you for providing this additional information. I am updating the internal PBI tracking case to help make the case that additional documentation would be helpful here. Your efforts are extremely helpful to others who are experiencing the same issue. I am going to propose the above as an answer but if you find better information that explicitly resolves your issue, please mark that as the answer. 

    Please send solution to AzCommunity.



    Wednesday, August 28, 2019 6:07 PM
  • Hi Mike,

    I e-mailed my sample program WebReport3 as a .zip file, with a .txt appended to the end to try to get it thru e-mail.  Let me know if/when you get it, and if you have any questions.



    Thursday, August 29, 2019 6:39 PM