Prevent TypeCatalogueInstanceProvider from throwing a first chance MissingMethodException instantiating DefaultEnumerableValueFormatter

[akrock]

• Exclude FIE Assembly from TypeCatalogue
• Adjust CanBeInstantiatedAs to include checking for a public no-arg constructor.

All the tests were passing on .NET Core, I had issues w/ getting the full framework to run on my machine due to missing very old framework versions.

[akrock]

Addresses #1790

[akrock]

Oops forgot all the niceties of .net land that have come over the years, will fix the Array.Empty error.

[thomaslevesque]

Thanks @akrock! I have a few minor comments (some inline in the diff, and some here).

In the issue, @blairconrad said this:

we'd need to explicitly supply StringDummyFactory to the DynamicDummyFactory)

I think this should be changed in RootModule.cs. In fact, I'm a bit surprised that it doesn't break a test...

Also, you still have a build error. This is because in .NET Standard 1.6, TypeInfo doesn't inherit from Type, so you can't call HasDefaultConstructor on it. Changing typeInfo.HasDefaultConstructor() to type.HasDefaultConstructor() should fix it

[thomaslevesque]

In fact, I'm a bit surprised that it doesn't break a test...

Ah, I see. StringDummyFactory was introduced as an optimization. It works without it, it's just inefficient.

[blairconrad]

Ah, I see. StringDummyFactory was introduced as an optimization. It works without it, it's just inefficient.

Oh. I thought without it we might also have a first chance exception. I could be wrong. Either way, it'd be nice to keep using StringDummyFactory as @thomaslevesque suggested.

[akrock]

@thomaslevesque @blairconrad

I explicitly added the StringDummyFactory in RootModule to the collection of IDummyFactory that is discovered through the TypeCatalogue... is this what you had in mind?

[blairconrad]

@akrock, nice work. I did make one minor inline comment (about is object), but aside from that, I am very happy. I'd even say you could squash the commits up as you make that last change, only I don't want things to shift too much under @thomaslevesque.

I explicitly added the StringDummyFactory in RootModule to the collection of IDummyFactory that is discovered through the TypeCatalogue... is this what you had in mind?

Thanks for that.
Truth be told, I hadn't thought much about where the addition would be. I am happy for it to be in RootModule. An alternative would be for it to be nested inside the DynamicDummyFactory and supplied by its own constructor, but your approach seems as good to me.

It may come up in future discussion, so I'll comment here.
I considered asking for a change in scanning-for-extension-points.md, removing "its own assembly", but then I thought we might as well leave it. FakeItEasy is just doing a different kind of search. A manual one. @thomaslevesque , if you disagree, I don't mind if the bullet point goes away. Honestly, I think the behaviour is transparent to clients either way.

[blairconrad]

Thanks, @akrock!

[thomaslevesque]

I considered asking for a change in scanning-for-extension-points.md, removing "its own assembly", but then I thought we might as well leave it. FakeItEasy is just doing a different kind of search. A manual one. @thomaslevesque , if you disagree, I don't mind if the bullet point goes away. Honestly, I think the behaviour is transparent to clients either way.

I don't mind leaving it as is

[thomaslevesque]

Looks good to me, thanks @akrock!
Could you please squash the commits before we merge?

[akrock]

Squashed.

Thanks to you two for the great work you do on this project @thomaslevesque & @blairconrad

[thomaslevesque]

Thanks again, @akrock !

[blairconrad]

Indeed, thanks for your work, @akrock!