Perché la progettazione WPF non carica le librerie che chiamano in DLL non gestite?

Sto usando Visual Studio 2008, .NET 3.5 SP1 e ho un’applicazione di test con i seguenti moduli:

  1. una DLL C ++
  2. una DLL C ++ / CLI che utilizza # 1
  3. un’applicazione C # WPF che utilizza # 2

Quando provo a utilizzare le classi dalla # 2 come risorse nel file XAML di WPF, il progettista non mi consente di:

<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 

L’errore è: “Assembly ‘ClassLibrary1’ non è stato trovato Verificare che non manchi un riferimento all’assembly Inoltre, verificare che il progetto e tutti gli assembly di riferimento siano stati compilati.”

Ma quando uso una class dalla DLL C ++ / CLI nel code-behind della finestra principale dell’applicazione, tutto funziona correttamente. Class1 viene creato e nel suo costruttore chiama nella DLL C ++, nessun problema.

 using ClassLibrary1; ... public partial class Window1 : Window { public Window1() { InitializeComponent(); //use in code-behind Class1 tmp = new Class1(); tmp.FirstName = "foo"; Title = tmp.FirstName; } } 

Se modifico l’assembly C ++ / CLI, rimuovi la sua chiamata nella DLL C ++ e ricostruisci tutto, il progettista smette di lamentarsi e carica l’assembly C ++ / CLI senza lamentarsi.

Ho il sospetto che questo problema abbia a che fare con il punto in cui il designer WPF cerca le librerie dinamiche.

Poiché il designer di Visual Studio copia gli assembly in una posizione temporanea, ma non copia le dipendenze non gestite, è ansible incontrare questo problema.

La soluzione più semplice, sebbene non ideale, consiste nell’aggiungere una cartella contenente le dipendenze non gestite alla variabile di ambiente PATH , quindi avviare DevEnv.exe con tale PATH .

Puoi farlo sia:

  • Aggiunta della cartella alle variabili di ambiente di sistema utilizzando Computer -> Proprietà
  • Utilizzando un file batch che imposta il percorso e avvia DevEnv

Il problema con questa soluzione è che, man mano che le dipendenze non gestite vengono rigenerate, Visual Studio tende a “bloccarsi” su di esse o non usa quelle nuove e quindi si finisce per dover uscire e riavviare Visual Studio dopo aver usato il designer per ribuild completamente tutto e questo può essere un po ‘un dolore.

Non è una soluzione reale, ma a volte aiuta: ribuild usando “AnyCPU” (non “x64”, perché il progettista è un processo a 32 bit) e in modalità “Rilascio”, chiudere e riaprire Visual Studio. E, sì: questo è molto fastidioso …