.NET 8 Android Failed to resolve type MvvmCross.Binding.BindingContext.IMvxBindingContextStack when calling MvxActivity.SetContentView about mvvmcross HOT 8 CLOSED

I cannot reproduce, I've been running and debugging an App on Android which does exactly this all day.

from mvvmcross.

I did test with 9.2.0-beta.3 and it also occurs in 9.2.0-beta.3.

Looking at the change history I narrowed it down to the changes made to the plugin code.

If I override InitializeApp in setup.cs to the following then the exception is not thrown:

protected override void InitializeApp(IMvxApplication app)
{
   var pluginManager = InitializePluginFramework(Mvx.IoCProvider);
   app.LoadPlugins(pluginManager);
   base.InitializeApp(app);
}

My LoadPlugins Looks like this:

public override void LoadPlugins(IMvxPluginManager pluginManager)
{   
   base.LoadPlugins(pluginManager);
   pluginManager.EnsurePluginLoaded<MvvmCross.Plugin.Messenger.Plugin>();
   pluginManager.EnsurePluginLoaded<MvvmCross.Plugin.Visibility.Platforms.Android.Plugin>();
   pluginManager.EnsurePluginLoaded<MvvmCross.Plugin.Color.Platforms.Android.Plugin>();
}

Commenting out the 3 calls to EnsurePluginLoaded even with the change to InitializeApp will cause the Exception to return.

from mvvmcross.

None of the plugins you are loading are necessary for bindings to work.

Are you overriding InitializeBindingBuilder or CreateBindingBuilder in your Setup.cs file by any chance?

from mvvmcross.

I am not overriding InitializeBindingBuilder or CreateBindingBuilder
I did some more digging and was able to remove the calls to EnsurePluginLoaded for the Visibility and Color plugins.

So the following setup to not get the exception is:

protected override void InitializeApp(IMvxApplication app)
{
   var pluginManager = InitializePluginFramework(Mvx.IoCProvider);
   app.LoadPlugins(pluginManager);
   base.InitializeApp(app);
}

public override void LoadPlugins(IMvxPluginManager pluginManager)
{   
   base.LoadPlugins(pluginManager);
   pluginManager.EnsurePluginLoaded<MvvmCross.Plugin.Messenger.Plugin>();
}

My MainActivity's ViewModel does use dependency injected Services which use IMvxMessenger (injected into the service's constructor). With the recent change moving the plugin initialization after the call to initialize app could that be causing this issue? I would have expected an IOC resolve exception if that was the case.

from mvvmcross.

I cannot reproduce this at all, it would be helpful if you had a sample project where this is occuring.

One more question, do you have any plugins loading in your App instance or just in Setup?

from mvvmcross.

I am working on a sample project, however I think I may figured out the cause.
I am dependency injecting IMvxMessenger into the AppStart constructor. In the sample project I was working on, I get an IOC Resolve exception when I do this. This is a slightly different error then my original exception, however it does match my theory in the previous post.

In my original project, I have around 15 services injected in the AppStart Constructor. If I only inject
IMvxApplication, IMvxIoCProvider, IMvxNavigationService and then resolve the other 12 in the ApplicationStartup override the exception is not thrown.

So it seems like with the recent changes IMvxMessenger can no longer be injected into the AppStart constructor?

from mvvmcross.

Yes, the order of loading has changed, due to preparation for a different IoC container, and removal of callbacks when certain things get registered in the container.

The Messenger plug-in doesn't need anything else to function, so it should work if registered earlier.

Let me check if maybe App start can be ordered differently too. I get that you want to be able to use dependencies in there to determine which VM to navigate to etc.

from mvvmcross.

So, I've been looking through MvxSetup to see if IMvxApplication initialization can be done later in the process so you can rely on constructor injecting dependencies, but that hard to do, as many of the things we register at startup depend on it or IMvxViewModelLocatorCollection it implements.

So I can only say that injecting dependencies in the ctor of IMvxApplication can work with some dependencies, but not plugins etc. as they are registered later.

The best I can do is to call Initialize after plugins have been loaded and and just before InitializeLastChance so you can lazily load some dependencies in that method.

from mvvmcross.