How to properly load a module's dependencies.

[bwcurless]

Hi,

I have been having a problem recently where I have a module called "ModuleA" in my example that has a view called "ViewA". I want to display a graph in ViewA using the LiveChartsCore package, and have followed their example. I load ModuleA from a directory module catalog, and navigate ViewA into a region in my MainWindow in my shell app (Modules). Everything works fine if I have a reference from my main Shell "Modules" application to my "ModuleA" class library, but once I remove this reference (because I want my module to be truly modular, and my shell shouldn't have to know that my module wants to draw a graph using LiveChartsCore), ViewA fails to be created. In certain cases, calling InitializeComponent() on the view fails, in others I get a BadImageFormatException.

I have made a minimum reproducible example from the directory module catalog Prism WPF sample. I modified it a little bit to "CopyLocalLockFileAssemblies" to output so that my nuget packages in my "ModuleA" project would be copied to the output. I also modified the post-build event to copy all files from my module output to the main shell output folder as well. ViewA just has a single CartesianGraph Control in it from LiveChartCore.

How should I get the dependencies of "ModuleA' to be correctly loaded. It is as if the deps.json file for ModuleA is not followed for my module. Should the deps.json of a Module that the Prism AssemblyResolver calls LoadFrom() on be correctly traversed? Maybe this is more of a .NET Core question, but I was hoping to figure out how others have successfully made Prism modules that can have their dependencies successfully loaded at runtime.

Thanks!
Brian

Module_Dependencies_Example.zip

[brianlagunas]

Have you read the docs on defining a dependency when loading via a module catalog? https://docs.prismlibrary.com/docs/modularity/index.html#discovering-modules-in-a-directory

Your sample is not runnable, and you are using a very old version of Prism that is not compatible with .NET Core. You should upgrade.

By the way, deps.json is not a thing in prism.

[bwcurless]

Thanks for the quick response.

Yes I've read the documents, and watched your PluralSight videos, as well as some of your other videos. Thanks for making them they were very helpful. In reading the documents, I was under the assumption that "ModuleDependencies" were only to be used for dependencies that contain an implementation of "IModule". In my case, LiveChartsCore.SkiaSharpView.WPF is just a Nuget package, and doesn't contain an IModule definition with RegisterTypes and OnInitialized. Maybe this is a big misunderstanding on my part, if so that would explain how I am supposed to successfully load other dependencies.

1. Do you refer to plain-old Nuget package dependencies "Modules" in the Prism documentation? Or are only class libraries that contain an implementation of "IModule" considered "Modules"?

If the answer to question 1 is 'Yes', then I don't see how the DirectoryModuleCatalog is supposed to discover these Nuget packages as modules. If we look at the DirectoryModuleCatalog.netcore.cs class in Prism, it looks like it filters out any .dll's that do not implement IModule. DirectoryModuleCatalog

Sorry about the example. I pulled it out of the larger Prism-Samples-Wpf solution just before uploading and the package dependencies were broken. I was using Prism 9.0. I have fixed the example, tested it, and reuploaded.
Module_Dependencies_Example.zip

Thanks again,
Brian C

[brianlagunas]

Just like the Module DLL, you need to make sure all dependencies are also copied so that the main application can load them when the application starts.

[bwcurless]

I set the property "CopyLocalLockFileAssemblies" to "true" in my .csproj file for my module, and I made sure that the post-build event recursively copies the build output to my ModulePath. Would this not work? It seems to be copying all my dependencies over. In fact, if I add a project reference to my module, then everything works fine. I have even diffed a working build with a non-working build, and the contents are almost identical, proving that the required dependencies are indeed present as you say.