0

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?

Seva Alekseyev
  • 59,826
  • 25
  • 160
  • 281
rlesias
  • 4,786
  • 3
  • 15
  • 20

1 Answers1

3

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:

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

    <bindingRedirect oldVersion="1.0.0.0-1.0.32.27762" newVersion="1.0.32.27762" />
</dependentAssembly>

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

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

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

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

Lukazoid
  • 19,016
  • 3
  • 62
  • 85
  • I know about binding redirects and how to use them in simple scenarios. However I was not able to make it work when different Prism modules reference different versions of the same assembly (I want to keep the different versions even after the application has been deployed) – rlesias Feb 21 '14 at 06:20
  • If this were possible, which I do not believe it is, what would happen if the referenced assembly had a static method somewhere? Would you expect two separate static methods (one per version) or would you expect both versions to use the same static method? The same question for static fields, you could get in a right mess. – Lukazoid Feb 21 '14 at 09:02
  • I would expect each module picking up the correct version depending on what is set up in its configuration file. That doesn't seem to work though. – rlesias Feb 21 '14 at 09:37
  • Take a look at my updated answer, I have given you a few more options and a bit of information from the MSDN. – Lukazoid Feb 21 '14 at 13:08
  • Thanks for the help. Maybe we should give up the module approach ang opt for completely independent contexts. – rlesias Feb 21 '14 at 15:09
  • You can use both assembly in the same code thanks to references alias : see https://stackoverflow.com/questions/11550981/need-a-way-to-reference-2-different-versions-of-the-same-3rd-party-dll – Orace Nov 20 '19 at 11:11