During plugin simulation, the private properties are getting reset to default(instead of mocked values)

[jordimontana82]

Continuing discussion that was raised here: jordimontana82/fake-xrm-easy#599 as it belongs to this repo.

[jordimontana82]

@AnoopRawat I believe what's happening there is that you're trying to mock a property on the entity record _seriesNumber, but I didn't see any setter that would map that property to an actual attribute / field name on the entity.

Plugin simulation takes a snapshot of the entity record before running it through the pipeline, therefore, if you tried to set any other property other than entity field names / values, they'll be probably ignored.

If the propery had a setter that would map the value to an actual field in the entity, then it probably should retain the value.

Hope this helps!

[jordimontana82]

Maybe you don't need pipeline simulation at all for this scenario, and you could just do testing the plugin normally via ExecutePluginWith? What you're trying to validate?

[AnoopRawat]

@jordimontana82 : Thanks for your reply, and yes this property (out of many other) is private and doesn't has any public setter (by design there is public method in Entity which set this private prop.), but we still need to have the mocked value for this private property (set by public method before plugin simulation).
and, of-course I'm able to test plugin normally via fakexrmeasy 👍 & other public setter properties do have mocked values, but we also need pipeline simulation for these kind of scenarios, without having public setter.
So is there any in-progress feature work going on (with library in upcoming version), which support this ? or changing PlugIn code to have public setter is only solution you see at the moment.?

[jordimontana82]

Thanks @AnoopRawat

Could you please post what the .CreateSelf() method of your XrmServiceProxy class is doing?

And, if you could, how the EntityBaseClass looks like, if possible?

My point was that the public getter / setter properties are not so important, but the fact that these values need to be written back to an attribute of the Microsoft.Xrm.Sdk.Entity class (theAttributes collection), because that's what the IOrganizationService understands and what the PipelineSimulation will use. When you generate a typed entity using, for example, CrmSvcUtil, it automatically generates setters and getters for these fields, which, ultimately, write back to that Attributes dictionary, which is then sent to the api.

FakeXrmEasy (and the CRM SDK / Dataverse Client) also use these properties in the Attributes dictionary.

[jordimontana82]

@AnoopRawat Did you have a chance to try this again?