Current filter:
                                You should refresh the page.
                                  • Hi team,

                                    I posted this issue https://www.devexpress.com/Support/Center/Question/Details/T812285/intermittent-webdocumentviewer-issues-in-azure-the-red-message-displaying-internal a couple of weeks ago, originally we thought we had a solution by setting the maxAllowedContentLength but the problem was inadvertently fix when we added the setting in the web.config the environment variable ASPNETCORE_ENVIRONMENT = Development was also added (incorrectly) and deployed.

                                    Once this was discovered and we removed the environment variable we went back to having intermittent issues which relate to the size of the data. If we run our solution locally and simply toggle the environment variable setting we can replicate it; production it fails development it works. We tracked down this ticket https://www.devexpress.com/Support/Center/Question/Details/T684507/net-core-report-does-not-show-in-production-environment we took the sample project supplied upgraded it to .net core 3.0 hard coded a large amount of data and we got the error setting the environment variable to development and it goes away. Doing the same steps in the sample project but without upgrading to .net core 3.0 and we didnt get the error.

                                    I have attached two projects the .net core 3.0 project with the hardcoded data where we got the error and the .net core 2 project where we didnt get the error, I have also attached a screenshot of the error we were seeing. It appears the conditions for the bug to happen are:

                                    .net core 3.0
                                    ASPNETCORE_ENVIRONMENT = Production
                                    Large amount of data

                                    Thanks,

                                    Jay

                                    P.S I was unsure if I should amend my original ticket as I had incorrectly marked it as solved.

                                1 Solution

                                Creation Date Importance Sort by

                                Hi Jay,

                                It looks like this issue is more related to your ASP.NET Core application configuration, rather then to our components. This is because your application limits the size of the response that is returned to the browsers, so our client-side code fails to parse the JSON data that was returned by the web server. In any case, I checked your project and found that the "IIS Express" profile of your application is hosted on IIS Express and the "WebApplication9" profile launches Kestrel. The web.config is ignored by Kestrel, this is why your solution does not work for this kind of environment. You need to use the Limits property of the KestrelServerOptions class to enlarge the limits for Kestrel. Check the How to increase file upload size in ASP.NET Core article for more information regarding this.

                                See also:
                                Use multiple environments in ASP.NET Core

                                Show all comments
                                • Jay Macilquham 1 09.20.2019

                                  Hi Vasily,

                                  This was the sample project taken from the ticket  https://www.devexpress.com/Support/Center/Question/Details/T684507/net-core-report-does-not-show-in-production-environment this isn't a deployed application. I assume you didn't run the application if you run the application locally via VS and the only thing you change is ASPNETCORE_ENVIRONMENT from Development to Production the report fails.

                                  The suggested setting to change in the supplied link is maxRequestLength the default value for this is 30mb there is no way the payload returned is greater than 30mb. That said I did try tweaking this value to a higher setting but I still go the error.

                                  Thanks,

                                  Jay

                                • Vasily (DevExpress Support) 09.23.2019

                                  Hi Jay,

                                  >I assume you didn't run the application if you run the application locally via VS and the only thing you change is ASPNETCORE_ENVIRONMENT from Development to Production the report fails.

                                  Actually, I tested your project on my side by using the latest build of .NET Core 3 (v3.0.0-rc1) and I was not able to replicate this issue by using both the "IIS Express" (with the ASPNETCORE\ENVIRONMENT set to "Development") and the "WebApplication9" (with the ASPNETCORE\ENVIRONMENT set to "Production") profiles. Check the attached video for more details. Maybe I missed something?

                                  >The suggested setting to change in the supplied link is maxRequestLength the default value for this is 30mb there is no way the payload returned is greater than 30mb.

                                  Note that I sent you the link to the How to increase file upload size in ASP.NET Core article just to demonstrate how to use the Limits property of the KestrelServerOptions class. The "maxRequestLength" property should not affect this issue as it controls the web request's size. And your issue is caused by the fact that the JSON content of the web server's response is cut.

                                • Jay Macilquham 1 09.25.2019

                                  Hi Vasily,

                                  You are correct the application runs fine when running under Kestrel but it doesn't when running under iis express or iis when deployed. In the attached recording I tried to show how when refreshing the same page/report which has hardcoded data the issue doesnt always appear (the recording shows it displays correctly once). Also in the response returned it appears it contains a duplicated section of the json twice. This sounds confusing but the recording will illustrate what I mean.

                                • Vasily (DevExpress Support) 09.26.2019

                                  Hi Jay,
                                   
                                  Thank you for your update. I was able to replicate this issue by using version 18.1.6. However, after upgrading the DevExpress components in this application to the latest version (19.1.6) in which we improved .NET Core 3 support, the issue is no longer reproducible on my side. So, I recommend you upgrade your DevExpress components to the latest version and check whether this fixes the issue on your side. Please refer to the Add the Document Viewer to an ASP.NET Core Application (19.1) to learn how to configure your ASP.NET Core application to use 19.1 version of our components there.

                                • Jay Macilquham 1 10.22.2019

                                  Unfortunately it didn't the only way we got the issue to disappear was to run the app out of process. Hopefully we can remove this workaround in the future but for now its the only way we got the reports to work.

                                • Vasily (DevExpress Support) 10.23.2019

                                  Hi Jay,

                                  Do you mean that you upgraded your project to v19.1.6, but the issue was still reproducible? Also, it is not completely clear what you mean by saying "run the app out of process". If possible, send us the upgraded version of this application, where the issue is still reproducible so that we will be able to replicate and research the same problem on our side.

                                • Vasily (DevExpress Support) 10.29.2019

                                  Hi Jay,

                                  I would like to inform you that we were able to replicate this issue in the context of the "Internal Server Error" errors occur while working with Web Reporting components in a published ASP.NET Core 3.0 applications thread. I passed this issue to our developers for further research. We will update that thread once we make any progress on this issue. Please bear with us.