IUnityContainer type not mapped when Unity Versions are different in PRISM based modules

Dec 28, 2010 at 10:22 AM


I am currently working on problem which is related to different version of PRISM used for Shell and a Module. I created a module which uses PRISM 2.1. I am trying to load this module into a PRISM Shell which uses PRISM 2.2. In my module, I am having constructor which accepts IUnityContainer as parameter. PRISM 2.1 uses Unity Framework 1.2 and PRISM 2.2 used Unity Framework 2.0.

When I tried to load the module, following error message is thrown and module load fails.

"The current type, Microsoft.Practices.Unity.IUnityContainer, is an interface and cannot be constructed. Are you missing a type mapping?"

When I checked on the loaded modules in debug mode, I am able to see both versions of Unity Framework assemblies are loaded in memory.

Any one has faced this problem before?



Dec 30, 2010 at 7:20 PM

The CLR treats types loaded from different assemblies as different types, even if they have the same name. Have you asked this question on the Prism forums? There's probably some people with experience about this over there, but I expect the answer is going to be "keep the versions the same."


Jan 3, 2011 at 9:24 AM
Edited Jan 3, 2011 at 12:08 PM

Thanks for the response. I did some more digging into the way Silverlight CLR behaves when multiple versions of assemblies are loaded. I realized that since Unity assembly name is different between 1.2 and 2.0, both the assemblies are loaded into Silverlight application but cannot resolve to correct interface type since shell created container and module expected container are different types since both are from different assemblies. This is the problem we are facing now and I see no technical solution for this problem other than using the same version of PRISM for both Shell and Module.

I already discussed this item in PRISM forum and got suggestion to use same PRISM version for both Shell and module.


Once concern with repeated change in name of the assembly or namespace impacts developing an Enterprise Platform using PRISM or Unity framework.  We request for keeping the namespace and assembly names stable for upcoming releases of Unity and PRISM.



Jan 3, 2011 at 12:06 PM

I did some more exploration of how loading of multiple version of assemblies works in Silverlight. Following are my observations.

i) Only one version of an assembly can exist in a Silverlight Application
ii) Loading multiple versions
    a. Older( First and Latest( next: If older version of assembly is loaded and then newer version is loaded, exception will be thrown by Silverlight Runtime. Whole application will crash.
    b. Latest first and older next (no breaking change in latest assembly): If newer version of assembly is loaded and then older version of assembly is loaded, older version of assembly will not be loaded and no exception will occur.
    c.  Latest first and older next (breaking change in latest assembly): If newer version of assembly is loaded and then older version of assembly is loaded, exception will occur since in case of breaking changes in latest version assembly.

Is my observation valid? Any comments?

My previous posting conclusion is based on this findings.



Jan 4, 2011 at 6:22 PM

Keeping the assembly version number the same despite there being changes will break a lot more than it'll help you. There are breaking changes in interfaces from Unity 1.2 to 2.0. Would you rather be debugging "Cannot load version xxx" or "Missing method" exceptions?

If you really want the same version numbers, since Unity and Prism both ship full source, your best bet is probably to recompile them both with a known, fixed version # and assembly names. Then when new versions come out recompile with that same version # / assembly name. At least that'll trick things into loading, but you'll probably still have issues.

This is an open question in the .NET world. MEF is trying to address some of this. the older Managed Addin Framework (MAF) was also an attempt, but ended up so complicated it wasn't usable even by experts.


Jan 5, 2011 at 2:00 PM

I am not suggesting to keep the version number same. I am suggesting to keep the assembly name and namespace as stable as much as possible. Hope I am clear with my suggestion. We are thinking in the same line as maintaining the PRISM and Unity code on our own. But definetly adds overhead for us.  I will share more lessons learned once we solve this problem.



Jan 5, 2011 at 5:49 PM

The version number is part of the assembly name. If you change that, you change everything else.

We're not planning on changing the name part of the assembly name or the namespace. Some of the internal stuff might move around, but the core stuff will be staying where it is.


Jan 10, 2011 at 1:15 PM


The problem I am facing is due to the change in Assembly name for Silverlight Unity. This is creating problem for me in handling the multiple version scenario.



Jan 11, 2011 at 3:27 AM

We changed the assembly name in Unity 2.0 due to difficulties people were having keeping the desktop and Silverlight versions straight. We most likely won't change the names again.


Jan 12, 2011 at 5:02 PM

Thanks for the support provided for this issue.