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
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