I have a a WPF prism desktop app with a few modules. In the past I've put all my localized resources in common resource files in the infrastructure assembly and referenced it in all modules.
But lately I have been wondering if that is indeed the right approach from a maintainence perspective. In essence it also sort of breaks modularity. Would having module specific resource files in the the modules themselves be a better approach in the long run?
All thoughts appreciated.
I never have references between the individual modules when using Prism (unless one module is indeed an enhancement of another). I tend to put shared resources, interfaces etc. in a 'common'-assembly that is referenced by all modules and the assembly containing the shell. Things that implement an interface is then retrieved via the IoC-container and the implementation is placed in the module where it 'belongs'.
As you write - having them in the infrastructure module breaks one of the ideas behind Prism.
As far as one of Prism's main targets is modularity it just seems obvious to put your resources only in the appropriate assembly. Sharing resources via one centralized assembly is the opposite of modularity. Doing it the centralized way will get you another type of DLL hell at the time you want to add more (optional) modules. You will have to update the common assembly without the knowledge of the modules that use the assembly. And determining which module is present just again violates the modularity itself. The other way is to always update the common assembly to the latest version. Whatever you do, following the centralized approach forces you to build all your modules backward-compatible.
This is my point of view at the moment. But as far as I'm working with Prism for only a few weeks now I'm not quite sure if my statement is the way how it should be done.