Is "True Modularity" possible with PRISM for SL?

Topics: Prism v2 - Silverlight 3
May 4, 2010 at 3:07 AM


My team is trying to find the answer the the question in the subject line.  Here's in a nutshell what were trying to do:

1. Develop a common set of components that we name Core.dll (Strong named)
2. Develop several modules that uses Core.dll
3. All different modules are assembled in Shell.dll using Prism
4. All modules can reference different version of Core.dll

Up to #3, we were smooth sailing.  #4 seems to break this modularity pattern down to its knees in Silverlight...

Have you come up against this situation and what do you usually do?  If you're going to tell me to recompile all modules against the new Core.dll, don't bother...



May 5, 2010 at 6:09 PM

Hi Francois,

The modularity approach of Prism makes it possible to isolate modules from each other, and they can be loaded into the application as independent components in a loosely coupled way but allowing communication between them.

If I understood correctly, your scenario would require having different versions of Core.dll loaded into the application. However, it isn’t possible to load multiple versions of an assembly on the same AppDomain (you can read more about that on this article). Although you could have multiple AppDomains (which is possible, as explained on this thread), it isn’t supported on Prism, and it has some complexities.

A possible approach for your situation would be to make the shell reference a single version of Core.dll, register all its components in the Container with their respective interface mappings, and make all modules reference an interface through which you consume that implementation. That would avoid referencing Core.dll in several modules, so changes on that assembly wouldn’t imply that you have to recompile all modules against the new version.

I hope you find this helpful.

Guido Leandro Maliandi