Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ViewModelLocationProvider should use DI instead of Reflection to create instances #52

Closed
karlfl opened this issue Jun 1, 2015 · 2 comments

Comments

@karlfl
Copy link
Contributor

karlfl commented Jun 1, 2015

I stumbled across this when trying to fit my MEF samples to the Prism 6.0 code base using the ViewModelLocator.AutoWireViewModel . I have a single [ImportingConstructor] for my View Model with one parameter (my business service), but the ViewModelLocationProvider is using Reflection to get the View Model instantiating it with the default constructor. Therefore when the module attempts to display my view, I get this exception. "No parameterless constructor defined for this object." Should the ViewModelLocationProvider be using DI to get the View Model instance instead of Reflection?

@karlfl karlfl changed the title ViewModelLocatorProvider should use DI instead of Reflection to create instances ViewModelLocationProvider should use DI instead of Reflection to create instances Jun 1, 2015
@brianlagunas
Copy link
Member

BY default, the VML does not use DI, because that would be creating a dependency on a specific Container that you may not want to be using. So, by default we use reflection. But, if you want o use DI, then you can easily use your own container of choice by overriding the SetDefaultViewModelFactory method. So if you want to use MEF, you can.

See this post: http://brianlagunas.com/getting-started-prisms-new-viewmodellocator/

@lock
Copy link

lock bot commented Feb 1, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Feb 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants