Adding/Removing PreImage on RegisterPluginStep<T> does not update plugin registration

[bo-stig-christensen]

Adding or removing a PreImage using RegisterPluginStep.AddImage(ImageType.PreImage) does not trigger an update of the plugin registration, which results in a NullReferenceException if using the PreImage entity.

Although not tested, the same is most likely the case for PostImage.

[TomMalow]

Seems similar to #19?

After Reading it again, it seems like a different issue.

[bo-stig-christensen]

I just did another test and there is only a bug if you do not specify attributes on the image.

Initial registration without image:

            RegisterPluginStep<T>(
                EventOperation.Update,
                ExecutionStage.PostOperation,
                Execute)
                .AddFilteredAttributes(x => x.dg_SomeField);

Updated registration that triggers bug:

            RegisterPluginStep<T>(
                EventOperation.Update,
                ExecutionStage.PostOperation,
                Execute)
                .AddFilteredAttributes(x => x.dg_SomeField)
                .AddImage(ImageType.PreImage);

Updated registration that triggers Daxif to update in D365:

            RegisterPluginStep<T>(
                EventOperation.Update,
                ExecutionStage.PostOperation,
                Execute)
                .AddFilteredAttributes(x => x.dg_SomeField)
                .AddImage(ImageType.PreImage, x => x.dg_SomeFieldOrSomeOtherField);

I ran into this at some point in the past, but it disappeared again, probably due to wondering about "why the null exception" and then changing filtering attributes... maybe ;-)

[mlRosenquist]

I can replicate the bug. The PreImage is indeed not available when following the described steps.

I've looked into daxif's behaviour and it creates and updates the sdkmessageprocessingstep and sdkmessageprocessingstepimage entities correctly in the scenario.

I crosschecked daxif's behaviour with the Plugin Registration tool in XrmToolBox for the scenario. It shows that doing the equivalent steps results in the same bug. It seems to be a platform error.