ExportFactory isn’t in WPF 4 (but will be in 4.5). The assembly above was for .NET 3.5, though -

I had some issues with this, and would recommend recompiling everything against .NET 4. The assembly, as downloaded above, may have issues as it’s built against 3.5.

That being said – I believe the other problem is that should be:

public IEnumerable> ViewModelFactories

In addition, I believe you need to do some extra decoration on the exports if you want [ImportMany] to work with ExportFactory. See: http://stackoverflow.com/a/8450345/65358

-Reed

Basically I was following John Papa’s blog on how to use mvvm light framework and mef.
http://johnpapa.net/simple-viewmodel-locator-for-mvvm-the-patients-have-left-the-asylum

For the ViewModelIndexer class when I called CompositionInitializer.SatisfyImports(this); My [ImportMany("ViewModel", AllowRecomposition = true)]
public IEnumerable<Lazy> ViewModelsLazy { get; set; } variable populated correctly but not my [ImportMany("ViewModel", AllowRecomposition = true)]
public IEnumerable<ExportFactory> ViewModelsFactories
{
get;
set;
}

which utilizes the ExportFactory class. I noticed that the export factory class is in the ComponentModel.Composition.Initialization.Desktop_4 under both System and Microsoft. What am I missing? I’m new to WPF so I’m not really understanding where the disconnect is. I stepped into the
CompositionInitializer.SatisfyImports(this) and traced it but i’m still not fully understanding how to solve this issue.

Help please!

There is one thing that might be detrimental to my approach I thought about and that is that if any of the imports change during execution apparently the imports will not be recomposed/updated. From what I am reading that really the main difference between SatisfyImportsOnce and SatistfyImports. I dont know if I need to worry about it for the particular case Im interested in but perhaps others would have an issue with my approach. It is a bit frustrating the Microsoft did not include those composition calls for WPF layer because I am not completely happy with using my technique but I guess until I find some weakness to it Ill be using it. So far the code is working as I would expect it to.

So I found a guy who was making a call to MefBootstrapper.Container.SatisfyImportsOnce(object). Well, I took this info, and during my call to ConfigureContainer I simply set a static member of my App : Application class to the container, and then call the SatisyImportsOnce in the constructor of my view and my view model . Everything worked perfectly, all my imports on the view began to populate including my reference to the ViewModel itself and then all my view model imports were populated as well. It just seems this approach is so much simplier than incorporating this code presented here. I think what I did appears to have accomplished the same thing, the only ‘bad’ thing I guess is using a static global to reference the container, but I dont even think thats all that bad.

I am not sure what the difference is between SatifyImports but from the documentation the only ‘disadvantage’ I see is that it is not available for recomposition after using this method. I am not sure for what I am doing its a big deal, but if anyone reading this can comment on any fault in my method please I would love to hear it because I dont know if what I did is exactly right, all I know is it appears to work.

The problem is that you need to make the application that’s running set this, not your DLL. I’m not sure there’s a good way to do this for a setup project, short of moving your DLL into an executable and launching it. This post’s technique may or may not work, but it could be worth testing in this type of scenario.

I have a typical situation. I have a project that is using the mixed mode dll. I have set the option useLegacyV2RuntimeActivationPolicy = “true” in the App.config file. Now I have a set up project which is using primary output from my dll having useLegacyV2RuntimeActivationPolicy = “true” . When I install the setup, I am getting the error
Mixed mode assembly is built against version ‘v2.0.50727′ of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

Is there a way to change the configuration or adding a configuration to the set up file so that I can fix this error in my setup.

Any help greatly appreciated.

Thanks in advance

What is the proper/best way to fix this? I believe you could add a CurrentItemURI property to the MainViewModel class and update and bind to that instead of the URI property. Alternatively, you could bind to FeedViewModel.SelectedFeedItem.Link (and not update the URI property).

Thanks,

Rob

This is required only because there is no overload for TaskFactory.StartNew that takes a TaskScheduler but not the token and creation options. The only other option is to create the task, then use Task.Start(scheduler). Otherwise, you need to specify the other items, as the Task API just exposes it that way.

-Reed

when starting a Task directly on the UI thread why the need for the cancellation token and TaskCreationOptions?

thanks
Paul

As for MVVM being an architectural pattern, that’s pretty well established. Even look at Wikipedia: http://en.wikipedia.org/wiki/Model_View_ViewModel …

Thanks

MVVM is not just about the presentation layer – it’s the overall architectural pattern.

The “Model” in MVVM is the same core model that’s holding your domain/business logic. The ViewModel is where you’d put any application specific bridge code that’s required. It’s purpose is to take your Model and expose it to your presentation layer (View).

One of the main goals with MVVM is to keep the “Model” pure – you should be able to use your direct business logic and domain data without change. The ViewModel is where you place the code required to adapt your model for presentation.

-Reed

Best Regards,
Rohit

If you’re working on code that interacts with your business logic, and is specific to your application at hand, MVVM is appropriate.

If you’re making a reusable control that’s intended to be used within the View layer from any application, your code is really “pure View” related, and MVVM doesn’t really apply. In this case, there is no Model, which means a ViewModel doesn’t make sense (its purpose is to bridge between the View layer and your Model).

The same is true in Windows Forms – When writing a custom control, you don’t necessarily think in terms of architectural patterns like MVP, but rather making a single, reusable component.

Only Microsoft could have come up with such a Unified Model that makes so much sense.