0

I'm devolping a WPF application, using Prism 7.2. I have a module, which implements the IModule interface, where I register the views and viewmodels in the RegisterTypes method, e.g.:

containerRegistry.Register<IPanelOptimizationViewModel, PanelOptimizationViewModel>();

The problem arises when I try to resolve the implementation:

var vm = containerProvider.Resolve<IPanelOptimizationViewModel>();

whereupon I get the following Unity.ResolutionFailedException: 'Resolution failed with error: No public constructor is available for type XXX.Infrastructure.Interfaces.IView.'

The PanelOptimizationViewModel class derives from a base class:

public class PanelOptimizationViewModel : ViewModelBase, IPanelOptimizationViewModel
{
     public PanelOptimizationViewModel(IPanelOptimizationView view, IPanelOptimizationInputViewModel inpVM) : base(view)
}

and the ViewModelBase looks like this:

 public class ViewModelBase : BindableBase, IViewModel
 {
     public IView View { get; set; }

     public ViewModelBase(IView view)
     {
         View = view;
         View.ViewModel = this;
     }
 }

The interfaces IView and IViewModel are defined in a common Infrastructure project. They are not registered anywhere in the container, but if I remove the IPanelOptimizationInputViewModel parameter, no runtime exception is thrown - leading me to think that I don't need to do this, either.

As far as I have been able to understand, the Unity.Container will use the "most parameterized" constructor (see Unity not using the default constructor of the class), but I cannot provide a parameter in the Register method to specify this, as one apparently could before (pre Prism 7's container abstraction), with the RegisterType method.

How to solve this? Is there an overload of the Prism.Ioc.IContainerRegistry.Register method that allows me to set up the registration for constructor injection?

Should I work directly with the Unity container?

Basically, I am trying to inject a child view's viewmodel into the constructor of my "main" viewmodel, but this does not go well as long as the wrong constructor is called on the base class, with the wrong set of parameters... (if that is what is happening).

Needless to say, all child views and viewmodels have been registered in the RegisterTypes method in the module.

Any help on this would be greatly appreciated

olejhar
  • 1
  • 1
  • 1
  • Resolving which type exactly do you get the `ResolutionFailedException`? `IPanelOptimizationViewModel`, `IPanelOptimizationInputViewModel ` or something else? – Haukinger Sep 25 '19 at 12:18
  • I try to resolve `IPanelOptimizationViewModel`. The **Unity.ResolutionFailedException** is thrown by `PopupWindowAction` class in `Prism.Interactivity`, if that gives any additional information as to what causes this problem – olejhar Sep 25 '19 at 12:23
  • I mean - resolving `IPanelOptimizationViewModel` includes resolving, for example, `IPanelOptimizationInputViewModel`, and it's important which one of these `Resolve`s throws. You wrote that removing the dependency on `IPanelOptimizationInputViewModel` removes the exception, so it seems natural that that one or one of its dependencies causes the exception. – Haukinger Sep 25 '19 at 14:55
  • Well, this is embarrassing. I found the issue. Instead of defining a variable of type `IPanelOptimizationInputView` in the constructor to the `IPanelOptimizationViewModel`, I had defined one of type `IView`. Problem solved. Thanks for the help, anyways, @Haukinger – olejhar Sep 25 '19 at 15:04

1 Answers1

0

Should I work directly with the Unity container?

Yes, you can evade Prism's "abstraction" of the container by calling the GetContainer() extension method (for your container).

containerRegistry.GetContainer() // here you get a plain IUnityContainer
                 .RegisterType( ... );
Haukinger
  • 10,420
  • 2
  • 15
  • 28
  • Yeah, thanks! I tried that after I wrote the original question. It doesn't seem to solve the problem, though. I also tried to register the `IView`interface in the `RegisterTypes` method in the `App.xaml.cs`, but to no avail... – olejhar Sep 25 '19 at 12:00