Jun 14, 2012 at 5:43 PM
Edited Jun 14, 2012 at 6:00 PM
Based on my understanding you could obtain this information from the ModuleCatalog
instance which keep track of what modules are available to the application, which modules may need to be downloaded, and where the modules reside.
For example you could retrieve this instance from the container, through its mapped interface, like this:
Also, I believe you could benefit from the use of the LoadModuleCompleted
event provided with the ModuleManager,which will allow you to track when a module loads or fails to load.
You could find more information about this in the following section of the Prism documentation:
On the other hand, if you want to debug a module that is dynamically discovered, as far as I know you should have to use a
post build events in your module's project to automatically store the modules' assemblies in the desired folder after a successful build. To see the
post-build events configuration, right-click a module project, and then click
Properties. In the Properties dialog box, click the
Build Events tab.
An example of this could be like the ones used for ModuleA and
ModuleB in the aforementioned sample:
xcopy /y "$(TargetPath)" "$(SolutionDir)Prism4Demo\$(OutDir)Modules\"
xcopy /y "$(TargetDir)FsTaskButton.dll" "$(SolutionDir)Prism4Demo\$(OutDir)"
Another example can be seen in the ones used in the
Modularity Quickstart provided with Prism.
I hope you find this helpful,