With Prism, is it possible for two modules to reference different versions of the same assembly?

In my company, different teams are developing different modules of the same product based on WPF. Some modules reference the same assemblies e.g. Log4net, in-house framework, etc... To minimize the impacts, we would like each team to be able to update the version of the assemblies referenced by its module without forcing other teams to do the same. Is it possible with Prism?


This is possible but has nothing to do with Prism. What you will need to look at is using binding redirects.

Binding redirects allow you to specify that any reference to version X of an assembly should actually use version Y. This way the different teams may update their dependencies separately to one another but when it comes to deploying the application, you may configure the binding redirects to all point to a version of the assembly.

It is often usual to redirect the references to the most recent version of an assembly which has not introduced any breaking changes. Breaking changes could result in exceptions at runtime.

Here is an example of a binding redirect:

    <assemblyIdentity name="OurInHouseLibrary" publicKeyToken="32ab4ba45e0a69a1" culture="en-us" />

    <bindingRedirect oldVersion="" newVersion="" />

This specifies that any reference to the assembly OurInHouseLibrary of versions through to version should now reference the assembly OurInHouseLibrary at version

I would suggest against it, but another option is to use the codeBase element to redirect to different assemblies, i.e.:

    <assemblyIdentity name="OurInHouseLibrary" publicKeyToken="32ab4ba45e0a69a1" culture="en-us" />
    <codeBase version="" href="v1.0\OurInHouseLibrary.dll" />
    <codeBase version="" href="v1.1\OurInHouseLibrary.dll" />

Here is an article from Microsoft explaining why loading multiple versions of the same assembly is a bad thing. One of the main issues is with Type identities, as you will not be able to use the type from one version in place of the type from another (including being unable to cast them).

Need Your Help

Are there ways to improve NHibernate's performance regarding entity instantiation?

.net performance nhibernate

while profiling NHibernate with NHProf I noticed that a lot of time is spend for entity building or at least spend outside the query duration (database roundtrip). The project I'm currently working...