Added Shell Page dependency resolution with DataTemplate and Shell global routes… by brunck · Pull Request #3375 · dotnet/maui (original) (raw)

This change has broken a lot of my pages as DI is being used to create the instance of the view and it automatically chooses the constructor with max number of arguments.

This change assumes that DI should be used to create the instance of the view. Some assumption given I never registered my views to the service provider, so I would not expect it to be resolved this way, and more to the point I don't want my view resolved this way and it would seem there is no way to opt out of this, which now causes me a headache.

Why can't the internal implementation attempt to resolve via the service provider i.e. sp.GetService(type) and if its null revert to using Activator.CreateInstance this would ensure all existing code just works! If I want to opt into DI for view resolution, simple I just register the view, just like I would register everything.

I get why developers would want DI resolution of the view and there are benefits, but if its only to inject a view model to set the BindingContext personally I prefer my approach, which is and attachable property that resolves the type from the service provider and sets the BindingContext . This way you are not restricted to the router for DI resolution it can be applied on any BindableObject and better still in Xaml, no code behind, changing constructors etc etc etc. And this is why I don't need or want DI resolution of my views unless I specifically register them.

Can you advise is there any way to bypass this feature?