I've been using site-wide custom getters and setters through ContentDataInterceptorHandler for specific block types, used as property types, using something like the following in an initialization module with a dependency to EPiServer.Web.InitializationModule:
var contentDataInterceptorHandler = ServiceLocator.Current.GetInstance<ContentDataInterceptorHandler>();
However, in later CMS versions (I think sometime after 11.18) this no longer seems to work.Is anyone aware of any changes that would break this?
Likely related to this Ted?
It's very likely related to the new high performance IL generation as pointed out by Mark.
We have tried to detect when any property interceptor has been registered and in those cases fall back to the old Castle based IL to prevent any breaking changes. But there are many different ways to register such interceptors, and it seems like we may have missed your case.
You can try and disable the new proxy manually by setting the ProxyType value on ContentOptions to ProxyType.Castle. You probably know this, but it can be done in your configurable initialization module through a call such as:
public void ConfigureContainer(ServiceConfigurationContext context)
context.Services.Configure<ContentOptions>(x => x.ProxyType == ProxyType.Castle);
As Henrik said there is an intention that we should detect custom registrations of castle interceptors and if so use castle fro proxy generation. But apparently we fail to detect for some registrations. I have created an issue for this CMS-17430.
Thanks for the feedback and sorry for the inconvenience.
Thanks for your quick help, guys! Highly appreciate it!Explicitly setting the proxy type to Castle did restore the old behavior. We'll use that as a workaround for now and keep track of CMS-17430.
Are there any plans to introduce a different way of registering custom property interceptors (or something else to that effect)?