J'ai un projet de bibliothèque de contrôle C ++ 'compilé à l'aide de / CLR. Dans ce projet, il existe un contrôle utilisateur qui appelle une DLL natif. Ce contrôle utilisateur apparaît dans la boîte à outils de concepteur, mais je ne peux pas la faire glisser sur un formulaire. Sans référence à la DLL, le contrôle de l'utilisateur peut être utilisé, mais avec la référence, je viens d'obtenir le message "Impossible de charger l'élément de la boîte à outils" lorsque vous essayez de l'utiliser.
L'appel natif est fonctionnel et ne nuire à ce que l'utilisateur contrôle de toute façon. Le contrôle de l'utilisateur peut être affiché correctement dans le concepteur par lui-même avec l'appel DLL inclus. En outre, si le contrôle est ajouté manuellement à une forme et exécuté en tant que programme, il affichera également une amende.
Cela me fait penser que le problème est juste une question de concepteur de studio visual ayant besoin de savoir où se trouve cette DLL natif. Mais je ne sais pas comment le dire, ou où mettre la DLL afin de pouvoir le trouver. Autant que je sache, les paramètres du projet ne sont pas un moyen de faire référence à une DLL natif. Donc, cela a du sens pour moi que le concepteur ne se plaint que parce qu'il ne peut pas l'amener.
Y a-t-il un moyen de faire ce travail?
7 Réponses :
choses à essayer:
VS2010: Copiez la DLL vers le fichier vs2008, VS2010: Copiez la DLL dans le Fichiers du programme \ Microsoft Visual Studio 9.0 \ Common7 \ Ide \ Publicassemples Dossier.
AppData \ local \ local \ Microsoft \ VisualStudio \
J'utilise VS2008, vous ne pouvez donc pas fonctionner avec la première option. La deuxième option ne fonctionne pas comme indiqué. Le dossier «ProjectOrSemblies» est peuplé uniquement avec des dossiers nommés au hasard. Ces dossiers semblent être automatiquement générés par le concepteur assez fréquemment. Trop fréquemment pour tester car Visual Studio fait un nouveau dossier à chaque fois que je fourre quelque chose. Le dossier ProjectAssemplies regarde en théorie comme un candidat potentiel, mais le dossier aléatoire nommant qu'il ne le rend pas pratique.
Il me semble que le contrôle avec la référence à la DLL natif échoue car Visual Studio ne peut pas le charger. Essayez de définir la variable d'environnement de chemin d'accès mondial ou pour Visual Studio exécutable lorsque vous l'exécutez. Si cela n'aide pas, essayez de déboguer le comportement du temps de conception de votre contrôle et vous devriez pouvoir localiser le problème.
J'ai essayé de couvrir cela en plaçant la DLL natif dans le chemin C: \ Windows \ System32 comme commenté ci-dessus. Cela ne couvrirait-il pas ce que vous voulez dire?
@Nicholas: essayez d'enregistrer votre dll aussi - delphifaq.com/faq/windows_user/f668. shtml
Cela n'a rien à voir avec le chemin de la DLL, ou cela ne fonctionnerait pas au moment de l'exécution. Au-delà de cela, vous n'avez pas besoin d'enregistrer quelque chose que des dlls COM / ActiveX. Il n'y a pas de point (et il n'est en fait pas souhaitable) d'enregistrer des DLL qui seules les fonctions d'exportation utilisées par votre demande.
Votre soupçon que le problème est une question du concepteur Visual Studio nécessitant savoir où se trouve la DLL natif est partiellement droite. Ce n'est pas une question d'ignorance de son emplacement, mais plutôt du fait que le concepteur ne peut pas réfléchir sur des ensembles de mode mixte (celles qui contiennent un code géré et natif) afin d'instancier le contrôle. Cela provoque une boîte à outils d'afficher l'erreur que vous avez notée.
La solution de contournement consiste à compiler les fichiers source C ++ à l'aide de La solution de contournement ici consiste à compiler votre assemblage de contrôle de l'utilisateur à l'aide du paramètre "AnyCPu", ce qui le fera d'exécuter sous forme de processus de 32 bits dans un environnement 32 bits et un processus de 64 bits en 64 bits. environnement. Vraiment, c'est le meilleur des deux mondes, en supposant que vous avez écrit votre code correctement.
Enfin, si aucun de ces travaux, il y a toujours la possibilité de contourner le concepteur. Vous pouvez toujours écrire le code nécessaire pour instancier votre commande utilisateur et définir ses propriétés dans l'initialisateur du formulaire. Tout ce que vous perdriez, c'est la possibilité d'utiliser le contrôle à l'intérieur du concepteur à l'intérieur de Visual Studio. Tout fonctionnerait comme prévu au moment de l'exécution. / CLR: pure pour créer un EXE purement géré.
Une autre possibilité (aussi un "bogue par conception" dans VS) est que le contrôle que vous essayez d'ajouter a été compilé sous forme de composant 64 bits. Étant donné que Visual Studio est un processus 32 bits, il ne peut exécuter que des modules 32 bits. Bien que cela vous permet d'ajouter une référence à un assemblage 64 bits, il ne peut pas réellement compiler cet ensemble 64 bits et l'exécuter dans le processus.
Pendant que je fais des versions X64 et X86 de ce code, j'ai déjà isolé le problème de la plate-forme X64 que vous mentionnez comme ce n'est pas le problème ici.
En outre, en raison de ce problème de concepteur, je suis déjà en train de transmettre le concepteur et instanciant des contrôles de formulaire manuellement.
Je suis d'accord que la compilation avec le drapeau / CLR: pure passerait probablement par-passer le problème de concepteur ici, malheureusement dans ce cas, j'ai besoin d'un ensemble de mode mixte. Cependant, à mon avis, designer ne devraient pas avoir besoin de réfléchir sur une fonction qui utilise une DLL natif si cette fonction n'est qu'une fonction d'utilité de classe que le concepteur n'appelle pas.
@Nicholas: 1) Comment avez-vous une compilation "isolée" 64 bits comme "pas le problème"? Je ne parle pas d'assemblages mixtes de 32/64 bits. Le problème est Visual Studio est 32 bits, vous ne pouvez donc pas exécuter un contrôle de l'utilisateur compilé comme un assemblage 64 bits. Le seul moyen de savoir à coup sûr que ce n'est pas le problème est d'utiliser Tous les assemblages 32 bits. 2) Si vous instanciez les contrôles de formulaire manuellement, tout devrait fonctionner très bien. Vous êtes tous ensemble. N'est-ce pas le cas? 3) Votre opinion n'est pas vraiment pertinente et malheureusement non plus la mienne. Vous avez demandé une solution (ou au moins une explication) et j'ai fourni un.
(suite) Le concepteur VS doit pouvoir réfléchir sur l'ensemble pour instancier le contrôle de l'utilisateur qu'il contient. Il ne peut pas le faire correctement avec des assemblages de mode mixtes. Vous devrez diviser votre code ou éviter le concepteur en faveur de la création manuelle et de définir les propriétés du contrôle dans votre code (comme cela ressemble à vous déjà fait). Si vous acceptez que / clr: pure corrigerait vos problèmes, vous avez déjà une solution. Personne ne peut travailler de la magie ici, afin que vous puissiez aller de l'avant et accepter cela comme la réponse.
J'ai trouvé cela qui ressemble à un problème similaire?
SE SE SE SE SEMALEMENT OFFICILEMENT SIENNER UNE MODIFICATION DE VS2008 à VS2010 en tant que solution de contournement.
Avez-vous déjà trouvé une solution de contournement différente?
Ceci est un problème que je rencontre actuellement dans VS2008 avec un projet géré C # .NET à l'aide d'un projet géré C ++ Wrapper à l'aide d'un projet C ++ non géré.
Cela me semble certainement comme les assemblages temporaires designer que l'utilisation de Visual Studio utilise est un problème - il charge l'ensemble d'emballage de dépendance détecté dans le dossier temporaire, mais pas les dépendances non gérées de l'assemblage. Je peux voir que ceci est en C: \ Users \ Nom d'utilisateur \ Appdata \ local \ Microsoft \ VisualStudio \ 9.0 \ Projectassemblies. Lorsque j'essaie de charger le concepteur, un nouveau dossier est créé avec la DLL gérée, mais pas les dépendances non gérées. Malheureusement, je ne comprends pas ce que la personne dans la question du lien Microsoft ci-dessus est la solution de contournement en utilisant $ (Targedir).
En fait, j'ai trouvé si j'ajoute un dossier avec toutes les DLL à charge à ma variable d'environnement Windows Windows. Les formulaires concepteurs rendent bien. Maintenant, j'ai juste besoin de voir s'il y a un moyen plus élégant que d'avoir une voie abominante à cet égard, d'autres développeurs de l'équipe n'ont pas à gaver.
Liez votre bibliothèque avec /delayload:"Your_Native.dll ". Cela a résolu le même problème pour moi.
J'ai eu un problème similaire à celui-ci qui peut être le même que le vôtre (qui sait combien de choses pourraient le causer?), En gros, je ne pouvais pas laisser tomber des contrôles à un concepteur, mais les contrôles existants ont fonctionné bien la production et les tests.
Pour l'enregistrement, voici ma solution:
1) Modifiez les paramètres de votre solution sur x86. Cela m'a permis de mettre le contrôle sur le concepteur, de le déplacer, etc. 2) Lorsque vous avez terminé, vous pouvez revenir à AnyCPU ou X64. Je n'utilise vraiment que le concepteur pour simplifier la définition de quelques valeurs, et il apparaît que l'ensemble de 32/64 bits provoque des problèmes.
Vous pouvez créer une classe de base dans .NET et hériter de votre classe CLI à partir de cette classe de base. Le formulaire peut maintenant se référer à cette classe de base plutôt que directement au type CLI. Il trompe le designer.
Est le problème avec vs 2010 ou également avec vs 2008? Nous avons un problème similaire et paralysant qui nous a amené à revenir à VS 2008 ...
Je reçois ce problème avec vs 2008. Donc, vs 2010 n'est pas meilleur à cet égard?
Je pensais que l'ajout de la DLL natif au chemin C: \ Windows \ System32 pourrait réussir, mais malheureusement ce n'est pas le cas.
Même problème ici. Je peux créer un contrôle utilisateur sans ajouter de commandes ni de code. Mais je ne peux pas le faire le soin sur une forme. Mon contrôle utilisateur est dans le même projet que le formulaire.
C'est la 3ème plainte que j'ai vue à ce sujet la semaine dernière. Il pleut il coule, rien avant ça. À quiconque concernait: mentionne quel type de logiciel ou de mises à jour a été installée récemment sur votre machine.