No longer able to use custom getters and setters through ContentDataInterceptorHandler for specific block property types?

Ted
Ted
Vote:
 

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>();

contentDataInterceptorHandler.For<PropertyBlock<MyBlockType>>().Use<MyBlockType>(MyBlockTypeGetter, MyBlockTypeSetter);

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?

#230647
Edited, Nov 10, 2020 15:49
Eric Herlitz - Nov 10, 2020 21:09
Which version of Episerver.Cms.Core are you using?
Ted - Nov 11, 2020 8:01
11.20.1
Ted - Nov 11, 2020 13:57
I have verified everything works fine in 11.15.1, but breaks after upgrading to 11.20.1.
Eric Herlitz - Nov 11, 2020 14:23
There is nothing obvious to me in the release when filtering the release notes from 11.16 to 11.20 https://world.episerver.com/documentation/Release-Notes/. I did read something about changes in StructureMap and ServiceLocator registrations in breaking changes but cannot find the reference to that at the moment.
Ted - Nov 11, 2020 14:36
Thanks! Please let me know if you find any info on that breaking change, I couldn't find it either. I'm only aware of the breaking change in CMS 11 when certain StructureMap features were separated into a separate NuGet package. I'm not using any StructureMap features explicitly, however.
Vote:
 

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);
}
#230703
Edited, Nov 11, 2020 22:07
Vote:
 

Hi 

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.

#230730
Nov 12, 2020 6:48
Ted
Vote:
 

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)?

Thanks again!

#230735
Nov 12, 2020 8:56
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.