Prerequisites
- 10.0.0 (20210301)
- Angular
- .Net Core
I have integrated the DevExpress report server, and have found that my repository which supplies the data to the report, is not applying the ISoftDelete filter when a debugger is not attached.
Various scenarios:
- My machine, IIS Express, with debugger - ISoftDelete works
- My machine, IIS Express without debugger - ISoftDelete works
- Azure, with debugger - ISoftDelete works
- Azure, debugger NOT attached, ISoftDelete does not work - all entities are returned
3 Answer(s)
-
0
Hi @hra
This filter is applied on code behind. Nothing comes to my mind which can cause this problem on Azure. Is it possible for you to share related AppService and Entity definition with us ?
Thanks,
-
0
Hi there,
There is alot of code, sharing is not easy. I could have a remote session with you however, and walk you through it. I think the issue comes from the fact that when the DevExpress report server generates the actual report, it's no longer executing within the http request that the initial controllers were created through. It's a horrible "background thread" approach that just seems to cause issues - unfortunately, its how the DevExpress report server is designed to work - and I don't see it changing any time soon.
When I dump the stack trace, it doesnt contain any frames from above the Controller - no ASP.net frames, no Castle Windsor, Abp or AspNetZero... so I think it's a newly spawned thread.
One thing I would like to try, is fully re-initializing the DI container for my controller. Can you provide me with example code on how to fully initialize the DI container?
i.e, how do I create the ServiceCollection and populate it with all the same convention registered services, logging, etc....
Thanks,
-
0
@hra's answer via email:
I have resolved the issue by rearranging the order in which I resolve dependencies and start the unit of work. There is no real consistency to the issue, there is definitely something wrong with how dependencies are resolved when hosted within Azure, as mentioned - there is differring behavior when the debugger is and isnt attached - an indication of a race condition.
