Why does the WPF designer fail to load libraries that call into unmanaged DLLs?

I am using Visual Studio 2008, .NET 3.5 SP1, and have a test application with the following modules:

1. a C++ DLL
2. a C++/CLI DLL that uses #1
3. a C# WPF application that uses #2

When I try to use classes from #2 as resources in the WPF XAML, the designer won't let me:

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:lib1="clr-namespace:ClassLibrary1;assembly=ClassLibrary1" <- ERROR 

The error is: "Assembly 'ClassLibrary1' was not found. Verify that you are not missing an assembly reference. Also, verify that your project and all referenced assemblies have been built."

But when I use a class from the C++/CLI DLL in the code-behind of the application main window, everything works fine. Class1 is created, and in its constructor it calls into the C++ DLL, no problem.

using ClassLibrary1;

...

public partial class Window1 : Window
{
    public Window1()
    {
        InitializeComponent();

        //use in code-behind
        Class1 tmp = new Class1();
        tmp.FirstName = "foo";
        Title = tmp.FirstName;
    }
}

If I modify the C++/CLI assembly, remove its call into the C++ DLL and rebuild everything, the designer stops complaining and loads the C++/CLI assembly without complaint.

I suspect this problem has something to do with where the WPF designer looks for dynamic libraries.

Because the Visual Studio designer copies your assemblies to a temporary location, but doesn't copy your unmanaged dependencies, you can run into this problem.

The simplest solution, although not ideal, is to add a folder that contains your unmanaged dependencies to the PATH environment variable, and then start DevEnv.exe with that PATH.

You can do this either by:

• Adding the folder to the System environment variables using Computer -> Properties
• Using a batch file that sets the path and then starts DevEnv

The problem with this solution is that as the unmanaged dependencies are rebuilt Visual Studio tends to "hang onto" them or not use the new ones and so you end up needing to exit and restart Visual Studio after using the designer to properly totally rebuild everything and this can be a bit of a pain.