Is it possible to customize DryIOC type matching to workaround embedded Interop COM assemblies type mismatch?

user_827532 0
Viewed 38

We are currently working on a Prism project using DryIoc as the backing container and we are running into problems with the embedding of Interop assemblies for our COM interop. In the past, when we had issues like this, for instance, with RhinoMocks, we were able to tell RhinoMocks to relax its type matching policy.

Our situation is like this:

//Main App assembly
IContainer.Register<MyComInterface>();

//Library assembly
IContainer.Resolve<MyComInterface>();

This exception is being thrown when trying to create a view model in the Library assembly that uses MyComInterface:

code: Error.UnableToResolveUnknownService;
message: Unable to resolve resolution root Interop.MyComInterface
  from container without scope
 with Rules with {TrackingDisposableTransients, UseDynamicRegistrationsAsFallbackOnly, FuncAndLazyWithoutRegistration, SelectLastRegisteredFactory} and without {ThrowOnRegisteringDisposableTransient, UseFastExpressionCompilerIfPlatformSupported}
 with FactorySelector=SelectLastRegisteredFactory
 with Made={FactoryMethod=ConstructorWithResolvableArguments}
Where no service registrations found
  and no dynamic registrations found in 1 of Rules.DynamicServiceProviders
  and nothing found in 0 of Rules.UnknownServiceResolvers

So the question would be: Is there a way to customize the type matching policy at registration time?

We don't have access to the resolution point since that's inside Prism. I combed the DryIoc source codes and the core of the issue here seems to be that type matching is done with Type.GetHashCode() which lead to these two types not matching:

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

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

Thank you

dryioc inversion-of-control c#
1 Answers

DryIoc uses RuntimeHelpers.GetHashCode(type) for the type lookup. But even if it will provide you the way to override this behaviour, what will you gain?

Because .NET still treats the types from the different assemblies as different and won't allow you to substitute one for another.

Update after comment:

If you see the pros of such addition, please file the issue or start the discussion in the DryIoc github repo.

user_24926690
Related