2010-07-23 5 views
1

J'ai un projet C# avec un UserControl.Problème lors du chargement de UserControl avec référence DLL en mode Design

Ce contrôle utilisateur dépend d'un dll particulier en mode mixte C de qui à son tour, agit comme une façade à un non géré C++ DLL

     C#   C++ Mixed   C++ Umnanaged 
    [ main app ] ---> [ myUC ] ---> [ OCShell.dll ] ---> [ OCC.dll ] 

Dans la vue de la conception, je ne peux pas ajouter le UserControl. Il dit qu'il existe une exception FileNotFoundException sur OCShell (ou l'une de ses dépendances). Cependant, via le code, tout fonctionne bien. Dans l'application principale (forme de Windows) je peux

myUC uc = new myUC(); 
this.Controls.Add(uc); 

et cela fonctionne très bien. Le bon code est exécuté correctement. J'ai vérifié avec Dependency Walker et tout est OK. Tout est copié correctement dans le répertoire Bin \ Debug \ et chacune de ces DLL se voit.

Ma conjecture est que l'éditeur de vue de conception ne vérifie pas les chemins appropriés pour ces DLL et renvoie ainsi une erreur.

J'ai aussi essayé de copier tous les dll à chaque répertoire possible dans ma solution, mais cela n'a pas aidé non plus

Répondre

2

Oui, c'est un problème. Le problème est que le code s'exécute dans Visual Studio, pas votre application. Le chemin de vérification utilisé pour rechercher les assemblys dépendants inclura uniquement les répertoires privés de VS (Common7 \ IDE \ PrivateAssemblies et PublicAssemblies), pas le répertoire de construction de votre projet. Vous pouvez le faire trouver OCShell.dll en le copiant dans l'un de ces répertoires, mais la DLL non managée va devoir être placée dans un répertoire que Windows recherchera lors de la recherche de DLL. Lequel, autre que le cache côte-à-côte Windows qui nécessite un manifeste, est limité à un répertoire de la variable d'environnement système PATH.

Ce ne sont pas des options agréables. La meilleure chose à faire est de s'assurer que le code dans ces DLL ne peut pas s'exécuter au moment du design. Vous le faites en utilisant la propriété DesignMode, ignorez les appels si elle est True. Cela doit être fait dans au moins le constructeur et l'événement Load. D'autres événements peuvent également être exécutés. Réduit également considérablement les chances que vous casserez Visual Studio en raison d'un bogue dans le code non managé. Si cela affecte la vue du contrôle au moment de la conception, vous devrez peut-être écrire un concepteur pour compenser cela.

+0

DesignMode totalement fait l'affaire, merci beaucoup – Eric

+0

Ok, il n'a pas "fait tout le tour" = ( – Eric

1

J'ai eu le même problème. Si vous avez une DLL, qui utilise beaucoup d'autres DLL, et probablement écrite en C++, elle nécessite souvent beaucoup d'autres dépendances. En runtime, ils sont résolus parfaitement, mais pas en mode Design. En utilisant la réponse de Hans Passant, vous devez placer ce code devant chaque appel de fonction, lié à cette DLL.

if (!DesignerProperties.GetIsInDesignMode(this)) 

J'ai eu 2 Connect() et 2 Déconnecter() appelle de ma DLL, et après avoir mis cela avant chaque occasion, le concepteur peut maintenant parfaitement charger la mise en page pour le UserControl. Merci pour la solution.

Questions connexes