Prism assembly reference failure: System.Windows.Interactivity

At last, I found the answer!

When DLLs in Prism modules are referenced, the .NET assembly resolution mechanism looks for the referenced assemblies in the /bin folder of the hosting application (i.e., the one with the Shell and Bootstrapper) rather than in the module’s bin directory (assuming you have set up your modules as separate projects in the solution, as I have).

By coincidence, my hosting application happened to reference all the other Prism DLLs, so when the modules referenced those, it just found them in the hosting application’s bin directory. However, my hosting application never referenced System.Windows.Interactivity, so adding it just to my module meant there was no such DLL to be found in the hosting applications /bin directory. The DLL is in fact being copied to the /bin directory of the module, but some quirk of the way assembly resolution works with Prism applications means that the app never checks for assemblies in that folder.

So, in short: referenced assemblies in Prism applications apparently need to reside in the /bin folder of the hosting application.

I’m going to look at some means of using configuration to make this work more cleanly and intelligently, but the core of the problem has at least been uncovered.

Leave a Comment