Allow customizing the Type matching policy at registration time

[hmartinez82]

DryIOC internally uses RuntimeHelpers.GetHashCode(type) for matching the type being asked for vs. the type that are registered.
This leads to type mismatch when using embedded interop assemblies and asking for a container resolution from a different assembly that registered the type. As an example, in a scenario like this:

Type 1
{
    Assembly: App
    Name: Interop.MyComInterface
}

Type 2
{
    Assembly: Library
    Name: Interop.MyComInterface
}

the types won't match.

Idea: Allow adding a custom type matcher when registering a type. So one can, for instance, tell DryIOC to not use the Type's hash, but instead a more relaxed matching policy like Namespace+ClassName

[dadhi]

@hmartinez82 //cc @yallie

Hi there.
The main practical problems with making type matching customizable is the performance and complexity.
The lookup by hash is done in the multiple places (even though I have tried to minimize them).
And the reason behind using RuntimeHelpers.GetHashCode(Type) instead of Type.GetHashCode is also win in performance.
Regarding complexity, I would need to modify the registry, cache, etc. to use the object instead of Type key, to accommodate for the user-defined Type ID (e.g. Name plus Namespace). Then I need to handle it or abstract over it in the usage points.

But I am open for ideas and PRs to resolve the aforementioned concerns, because all of this maybe just in my mind.

Another alternative that may work for you @hmartinez82, may be laziness of loading the final type and use the type name until the service is really requested for resolution, e.g. use the DynamicServiceProvider.
I believe the approach is already was tried here

DryIoc/test/DryIoc.IssuesTests/Samples/LazyRegistrationInfoStepByStep.cs

Line 97 in 43638a7

public void Lazy_import_of_commands_using_custom_DynamicRegistrationProvider()

by @yallie

I have even added the supporting functionality both into DryIoc and DryIoc.Mef.
@hmartinez82 I would suggest to clone the DryIoc repo and look directly into the code supporting this concept, specifically into

DryIoc/src/DryIoc.MefAttributedModel/AttributedModel.cs

Line 484 in 5aa7b57

public static Rules.DynamicRegistrationProvider GetLazyTypeRegistrationProvider(

If it is too complex, the good Idea would be to publish minimal example of code of what you want to achieve without using the container. But the example should be complete and compile-able, better in the form of unit test, so others may help you to transform to the working solution with DryIoc.