We have a software which allows to add custom features by plugins. Plugins may add their own GUI with own panels, controls, etc. For different reasons it is essential that all plugins and the host software run in the same AppDomain. We recently got into the situation where two plugins used a different version of the WPF toolkit. In this scenario every time a panel was opened which contained a WPF toolkit control the software stopped working because of a missing resource. It turned out that the wrong version of the toolkit was used to resolve the resource.
After digging further into the issue we could locate the root cause in the merged resource dictionary in Main\Source\ExtendedWPFToolkitSolution\Src\Xceed.Wpf.Toolkit\Themes\Generic.xaml:
The merged resource dictionary doesn't specify a specific version for the other resource dictionaries. So the fix which worked for us is to change it from:
```
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="/Xceed.Wpf.Toolkit;component/Themes/Generic/Brushes.xaml" />
<ResourceDictionary Source="/Xceed.Wpf.Toolkit;component/Themes/Generic/Buttons.xaml" />
...
</ResourceDictionary.MergedDictionaries>
```
to:
```
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="/Xceed.Wpf.Toolkit;v1.9.0.0;component/Themes/Generic/Brushes.xaml" />
<ResourceDictionary Source="/Xceed.Wpf.Toolkit;v1.9.0.0;component/Themes/Generic/Buttons.xaml" />
...
</ResourceDictionary.MergedDictionaries>
```
This way the correct version of the resources will be resolved. The full solution would likely include a way to insert the current assembly version where I hard coded 1.9.0.0.
Would it be possible to add this fix to one of the next releases?
Best regards
Christian
Comments: ** Comment from web user: emartin **
The problem is that just adding the "VersionSafeResourceDictionary" to the Generic.xaml file won't make the Toolkit work properly.
Here what the issues we found:
1)
All "absolute" pack uri like <Image Source="/Xceed.Wpf.Toolkit;component/MyRes.png />in the resources files were also referring to the wrong assembly.
2)
Each places were a resource use a static reference to one of the assembly type or value to identify a key (ex. <Style x:Key="{x:Static tk:MyType.MyProp}" ... />) the result may end with the wrong value or a crash if the property doesn't exist in the "wrong" version of the toolkit.
However concerning the issue #1, this has been fixed by replacing all our references to relative uri.
For #2, We didn't had time to review and replace all theses usage with the "{ComponentResourceKey }" syntax that will probably fix the issue. It is not very long but since the tests has already been started this fix won't make the cut for v2.0. We will check this for v2.1.