.net – Loose xaml referencing versioned assemblies

assembliesvb.netwpfxaml

I have a unique development situation and would like some input from others.

I have a situation where I need to load loose xaml files within a rich client application.
A given loose xaml file may have references to an assembly not currently loaded in memory
so the referenced assembly is loaded before the loading the loose xaml. The loose xaml and tied
assemblies are stored on different backend servers which are downloaded to the client and
loaded dynamically.

The loose xaml and/or assemblies are version specific and unfortunately the application can
not be shutdown between rendering xaml.v1 with assembly.v1 from server A
and xaml.v1 with assembly.v2 on server B.
Both assemblies use the same namespace declaration so "older" assemblies can still
work with "newer" ones for any given loose xaml.

The problem is, I do not get a reference to assembly.v2 if I load xaml.v2 which contains
references to "newer" features in assembly.v2.

I obviously cannot unload assembly.v1 from the app domain and I'm not sure if I can
reference items in xaml that are loaded within a different app domain through marshalling.

Any Ideas other than using different namespace references?

Best Solution

I'm guessing that you are already doing dynamic assembly resolution and loading? If so, then you could try substituting a fake assembly name in place of the real assembly name i n the Xaml - you can then use that in your assembly resolution code to load up and return the right assembly. e.g. if your original source Xaml is:

xmlns:myassembly="clr-namespace:MyApp.MyAssembly;assembly=MyAssembly"

and you know that Xaml wants v2 of MyAssembly, replace the assembly ref in the Xaml string before parsing it to:

xmlns:myassembly="clr-namespace:MyApp.MyAssembly;assembly=MyAssembly.v2"

.. then in your assembly resolution / load code, when you see the ".v2" bit on the end you look for and load that assembly instead.

Please let me know if I've misunderstood the question, or you aren't current doing any custom assembly resolution - that would certainly be the key in this situation I think.