On the probing topic, that's a DevForce/MEF thing. Because there is no manifest in WPF, the only way DevForce/Cocktail can build up the catalog is by probing every assembly in the same folder as your exe. That's the default behaviour. MEF doesn't differentiate between exe and dll, they are all just assemblies. This is actually a powerful feature, because it allows you to have a plug-in model, but yes it can result in what you are describing that it is picking things up that it shouldn't.

 

DevForce let's you control the probing, though. You'll basically have to exculde the files you don't want it to probe. See the following link.

 

However, our apps stopped working when we deployed them. They would crash without an error message and we would have to look at event viewer to see the crash report. We eventually found the problem to be that MEF was probing the other exe files and we had a EntityManagerFactory export per app. The app would fail because it was only expecting one import but found many. We also had the habit of naming the first viewmodel MainViewModel. This would fail as well because the bootstrapper would find multiple imports for the one view model it was expecting.

Two questions arise from this. 

First, our WPF error handling is lacking and I was wondering if there is a way to catch all errors, even ones as early as importing the VM into the bootstrapper, and show them without having to go to event viewer (which was not helpful at all). 

Second, why is Cocktail probing other exe files (or is this a MEF default). Shouldnt it only probe dlls? It seems like if you have code you would like to share it should be in a dll and not in an exe.