Don't miss out Virtual Happy Hour this Friday (April 26).
Try our conversational search powered by Generative AI!
AI OnAI Off
ContentLoader.Get<> sometimes doesn't return the castle proxy for the content type.
Hmm, very interesting. Never heard about this issue. What is actual object stored in cache?
Jan 25, 2017 8:05
Sounds a bit like this one, basically calling IContentLoader/IContentRepository before CMS has completed initialization.
http://world.episerver.com/support/Bug-list/bug/CMS-6113
Jan 25, 2017 8:39
I will see if I can find anywhere in the code where the content loader is possibly invoked early. We have a few scheduled jobs and custom init-modules that may be the culprits.
Jan 30, 2017 13:14
EPiServer version: 10.3.2
The easiest way to reproduce this error. At least in my case, is to start debugging the project via IISExpress. Wait until the start page has loaded. Shut down the debugging session and start up a new one. What will happen on the second startup is that the start page controller will receive a currentPage-instance that is not wrapped in a castle proxy, making all custom data.
I don't think IISExpress or debugging is the actual problem. We tend to see this issue turning up on our QA-deployment as well from time to time. That's a release build hosted on a real IIS.
I don't really know the quirks with castle proxies or EPiServer caching. But my investigation has lead me to believe that the object stored in cache can lose it's castle proxy wrapper somehow.
Calling CacheManager.Clear() whenever this happens solves the problem. The cache will be repopulated and the content loader will return castle proxies and cached castle proxies for some time. Eventually it will get corrupt again.
//Martin