Take the 2-minute tour ×

We have an application as well as a Visual Studio add-in that both load their (modular) functionality from Mef assemblies located elsewhere on a users machine than the application is installed itself.

Now one of our developers used Wpf (using Prism/System.Windows.Interactivity) to create the UI component for a new module but unfortunately now the module / Xaml Parser throws a XamlParseException saying that it cannot load System.Windows.Interactivity.dll and looking at the fusion log basically shows that the paths its looking for / in is the one the hosting .exe runs from, not where the Mef module (containing the wpf / xaml ui) resides in.

The System.Windows.Interactivity.dll does in fact reside in the Mef's module/assembly directory (referenced in that mef module / assembly and copy local set to true) so I was wondering how we would specify the namespace for System.Windows.Interactivity properly below so the assembly loading does in fact look in the assembly's directory aswell?

<UserControl x:Class="TestExplorer.Modules.DocumentChecks.DocumentChecksMainWindow"
             xmlns:TreeView="clr-namespace:TestExplorer.Modules.DocumentChecks.TreeView" mc:Ignorable="d" 
             d:DesignHeight="500" d:DesignWidth="500">

There is one entry here at SO that has the exact same problem (see Prism assembly reference failure: System.Windows.Interactivity), however the solution to add prism/system.windows.interactivity as reference to the hosting application is only a workaround, at best - it basically defeats the applications' modular purpose (leave alone that we cannot deploy the system.windows.interactivity into the devenv.exe's location in case users use our Visual Studio Addin.. and devenv.exe being the hosting process there).

share|improve this question
Could you use this to add the path to your MEF modules so it gets probed msdn.microsoft.com/en-us/library/15hyw9x3(v=vs.71).aspx –  colinsmith Aug 1 '12 at 20:17
Colin - thanks for the comment. And yes I was thinking about utilizing <probing privatepath="..."> but that only really works for the standalone version, it would still not solve it for the VS Add-In. I could also try to utilize the AppDomain.CurrentDomain.AssemblyResolve event and handle it.. but that still isn't quite an elegant solution. I was rather looking for a WPF/Xaml 'native' way. –  Jörg B. Aug 1 '12 at 20:28
I'm not familiar with plugins so don't know it's environment....just an idea off top of head could you do a LoadFrom on the interactity DLL somewhere before the UserControl gets used...then it will be loaded into the AppDomain...and it might see it's already loaded and use that. –  colinsmith Aug 1 '12 at 20:34
I'm having the same problem developing a Visual Studio add-in. Have you figured out how to solve this specific problem? –  Ralf de Kleine Aug 15 '12 at 11:44
@rdkleine in the end we went with handling the AppDomain's assemblyresolve events and 're-route' them to the requested assembly's actual place. Not the most elegant way & probably will cause some confusion down the road maintainability wise, but at least it's working for now. If anyone finds a real 'solution' without manual detours/interventions, I'd gladly take it. –  Jörg B. Aug 15 '12 at 20:35

Your Answer



Browse other questions tagged or ask your own question.