0

We are currently working with a large solution that contains a WCF project (.NET Framework 4.7.2) along with multiple .NET Standard 2.0 libraries.

We're trying to register these libraries with Unity (DI). Loading the libraries in the container works fine. However resolving these classes in a constructor fails. 

Unity.Exceptions.ResolutionFailedException: 'Resolution of the dependency 
failed, type = 'PROJECTNAME.Service.ITypeDependentonDbContext', name = '(none)'.
Exception occurred while: while resolving.
Exception is: InvalidOperationException - The current type, 
PROJECTNAME.DAL.Repositories.Interfaces.IDbContext, is an interface 
and cannot be constructed. Are you missing a type mapping?

More specifically, each library has a ModuleInit class where we register types on the ModuleRegistrar (for MEF2) like so: 

 public void Initialize(IModuleRegistrar registrar)
    {
        registrar.RegisterType<IDbContext, DbContext>();
        // etc 
    }

Then, in our .NET Framework project, we register types to the Unity Container:

   protected override void ConfigureContainer(IUnityContainer container)
        {
            container
               .RegisterType<ISomeService, SomeService>()
               .RegisterType<ITypeDependentonDbContext, TypeDependentonDbContext>();
                //etc
             ModuleLoader.LoadContainer(container, ".\\bin", "*.*.dll");
        }

Finally, in a class in the .NET Framework project, we have 

public class SomeService : ISomeService
{
    private readonly ITypeDependentonDbContext _typeDependentonDbContext;

    /// <summary>
    /// constructor
    /// </summary>
    /// <param name="typeDependentonDbContext"></param>
    public SomeService(ITypeDependentonDbContext typeDependentonDbContext)
    {
        _typeDependentonDbContext = typeDependentonDbContext ?? throw new ArgumentNullException(nameof(typeDependentonDbContext));
    }
}

The weird thing is that the exception is not thrown if we register ALL types that we depend on directly in the container. This is in contrast to an existing .NET framework solution where we register each type in the moduleInit class of that project, exactly as presented here. However this doesn't seem to work with .NET standard 2.0 projects.

Additionally, while debugging it seems that the classes seem to be registered just fine in the container - each interface is mapped to the correct implementation class. Things only seem to go wrong when we actually wish to resolve the dependecy in a constructor.

Does anyone have any ideas as to why this may occur?

Sreini
  • 80
  • 7
  • Maybe it's just a typo, but there is a casing difference between your declarations. One you've listed as `ITypeDependentOnDbContext` and another is `ITypeDependentonDbContext` – Erik Funkenbusch Dec 03 '18 at 15:11
  • @Erik Funkenbusch yes, thats a typo, should be fixed now – Sreini Dec 03 '18 at 16:07
  • You only changed one of them. The interface is still wrong. That is why I thought it was your problem, because you were requesting an interface that wasn't configured. – Erik Funkenbusch Dec 03 '18 at 16:21
  • thats what you get when you try to edit on your phone! – Sreini Dec 03 '18 at 16:29
  • I don't see where you're inject IDbContext in any of your methods, nor do I see you configuring it. You're also defining a constructor with a different name from the class. How is this code even compiling? You need to provide the actual code that exhibits the problem. – Erik Funkenbusch Dec 03 '18 at 18:14
  • Assuming the issue has something to do with the application of both MEF v2 and Unity. We have created a sample solution that tries to mimic your setup. Surprisingly, we don't see any issues running it. Check https://github.com/cveld/UnityMEFSample Are we missing some essential difference with your setup? – Carl in 't Veld Dec 03 '18 at 20:39

0 Answers0