NullReferenceException registering Plugin in simulated pipeline

[bwmodular]

Describe the bug Registering a plugin step in the XrmFakedContext is giving me 'Null Reference Exception: Object reference not set to an instance of an object'. Am I missing something in the registration?

To Reproduce See screenshot below - my test isn't even gettin past the Initialization stage, so the test itself is not running. I'm Initializing the Faked Context, setting UsePipelineSimulation to true, and then immediately trying to register a plugin and it fails.

FakeXrmEasy and Dynamics 365 / CRM version FakeXrmEasy v9 (1.57.1). Core Assemblies v 9.0.2.34

Screenshots

The only other thing that might be worth noting is that when I accidentally didn't specify the entity that it was being registered against (like this: _fakedContext.RegisterPluginStep("Create", ProcessingStepStage.Preoperation, ProcessingStepMode.Synchronous); the registration didn't fail (but then the plugin failed because it was firing on every single create of every entity).

Any ideas what I might be doing wrong?

[jordimontana82]

Hi Ben,

I've tried with one of the test plugins in the repo, using entity name, and registration steps similar to yours and I didn't get that exception. Could you please post the stack trace to check?

Thanks!

[bwmodular]

Hi Jordi, the examples in the repo work for me too. The stack trace gives very little away: That's all there is!

I will try creating a new test project from scratch and see if I get the same results... I'll also see if registering a different plugin or against a different entity has the same results...

Thanks Ben

[jordimontana82]

Excellent! Thanks Ben!

[bwmodular]

I made the smallest test I could and it still fails with the same error. This is with a different plugin (but same assembly) than before.

I'll start a new project next and also try it another pre-existing plugin testing project...

[bwmodular]

I'm getting the same error in another recent solution which has pretty much the same architecture, same versions of SDK, etc.

I think that means I can create a copy of this solution, remove all superfluous projects, one by one, see if it still fails, and remove anything else, stripping it down to the bare minimum and see if I can identify the problem.

[bwmodular]

I've taken a copy of the solution, and removed all projects apart from the plugins project, early bound and unit testing project. I've removed all code except a single plugin which does nothing and single unit test which just initialises the fake context and registers the plugin in the pipeline simulation. I've removed any unused NuGet packages. This is all that's left:

Same problem.

I suppose the next thing to try is to create a new solution from scratch, unless you have any other ideas...

[bwmodular]

Aha. Getting a little bit closer, I think.

Debugging a local copy of FakeXrmEasy shows me the line which is failing:

and in the immediate window I can see that the EntityTypeCode of the Account (and other early bound classes) is null:

I've no idea why this should be, but it does at least give me something to work on - this is a standard XrmToolBox generated EarlyBound class....

[bwmodular]

Ah, here we are. By default the XrmToolBox EBG sets this to false: giving this reason:

Setting it to True fixes the problem.

Given that our environments tend to be cloned from one another, I don't think there's a risk generating EntityTypeCode, so happy to leave this set to true. Glad to get to the bottom of this. I wonder whether (sometime in v2) it might be worth trapping this error, and alerting users that this is a likely cause of the problem...?

[jordimontana82]

Hi Ben ,

Thanks a mill for reporting this! Yes, I think the plugin registration step should, at the very least, check if there is no EntityTypeCode and if so, fallback to use the EntityLogicalName, maybe. Or else just use the logical name.

[jordimontana82]

Related to #496