probing privatePath and resource dictionary - wpf

Question

I have two problems with apparently different symptoms, which I think may be the same problem. Both problems occur on one machine, but not on others.
In one case a .NET library is loaded in an old C++/MFC application. This library opens a WPF window, which generates the following error:
Set property 'System.Windows.ResourceDictionary.Source' threw an exception.
Cannot locate resource 'resourcedictionaries/images/bitmaps_32_32.xaml'.
The second error occurs on starting a WPF application. The program crashes on loading and writes the following error into the windows event log:
Anwendung: Cs3SystemManager.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.IO.IOException
bei MS.Internal.AppModel.ResourcePart.GetStreamCore(System.IO.FileMode, System.IO.FileAccess)
bei System.IO.Packaging.PackagePart.GetStream(System.IO.FileMode, System.IO.FileAccess)
bei System.IO.Packaging.PackWebResponse+CachedResponse.GetResponseStream()
bei System.IO.Packaging.PackWebResponse.GetResponseStream()
bei System.IO.Packaging.PackWebResponse.get_ContentType()
bei MS.Internal.WpfWebRequestHelper.GetContentType(System.Net.WebResponse)
bei MS.Internal.WpfWebRequestHelper.GetResponseStream(System.Net.WebRequest, MS.Internal.ContentType ByRef)
bei System.Windows.ResourceDictionary.set_Source(System.Uri)
bei System.Windows.Baml2006.WpfSharedBamlSchemaContext+<>c.<Create_BamlProperty_ResourceDictionary_Source>b__342_0(System.Object, System.Object)
bei System.Windows.Baml2006.WpfKnownMemberInvoker.SetValue(System.Object, System.Object)
bei MS.Internal.Xaml.Runtime.ClrObjectRuntime.SetValue(System.Xaml.XamlMember, System.Object, System.Object)
bei MS.Internal.Xaml.Runtime.ClrObjectRuntime.SetValue(System.Object, System.Xaml.XamlMember, System.Object)
Ausnahmeinformationen: System.Windows.Markup.XamlParseException
bei System.Windows.Markup.WpfXamlLoader.Load(System.Xaml.XamlReader, System.Xaml.IXamlObjectWriterFactory, Boolean, System.Object, System.Xaml.XamlObjectWriterSettings, System.Uri)
bei System.Windows.Markup.WpfXamlLoader.LoadBaml(System.Xaml.XamlReader, Boolean, System.Object, System.Xaml.Permissions.XamlAccessLevel, System.Uri)
bei System.Windows.Markup.XamlReader.LoadBaml(System.IO.Stream, System.Windows.Markup.ParserContext, System.Object, Boolean)
bei System.Windows.Application.LoadComponent(System.Object, System.Uri)
bei Cs3SystemManager.App.InitializeComponent()
bei Cs3SystemManager.App.Main()
This application refers to the same resource dictionary which is referenced in the first error message. My strong suspicion is that it is the same basic error.
The resource dictionary is referenced with the syntax:
<ResourceDictionary Source="/McWpfResources;component/ResourceDictionaries/Images/Bitmaps_32_32.xaml" />
I have also tried the following syntax, but it did not make any difference.
<ResourceDictionary Source="pack://application:,,,/McWpfResources;component/ResourceDictionaries/Images/Bitmaps_32_32.xaml" />
Our installation stores executable files (.exe) into a directory called bin, and the DLL's into a subdirectory called bin\interop (some of them are interop wrappers for COM components).
For each .exe file, there is a matching .exe.Config file which speficies the privatePath, for example:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/>
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="interop"/>
</assemblyBinding>
</runtime>
</configuration>
If I copy the exe files down into the interop directory, neither of the problems occurs.
Clearly, the privatePath parameter is not working in this specific case (at least not working as I expect), but it does seem to work on other machines and in other applications.
Obviously, I can fix the error by putting everything in one directory, but apart from that, how can I fix the error?

Answer 1

Forget it. This was my error.
From a previous installation, the bin directory contained an old version of a DLL which is now installed into the interop subdirectory. This old DLL was being loaded in preference to the DLL in the subdirectory.
I might delete this question (or I might leave it as a cautionary tale).