Ich habe ein C ++ 'Control Library Project' kompiliert mit / CLR. In diesem Projekt gibt es ein Benutzersteuerelement, das eine native DLL aufruft. Dieses Benutzersteuerelement wird in der Designer-Toolbox so angezeigt, wie es sollte, aber ich kann es nicht auf ein Formular ziehen. Ohne den Verweis auf die DLL kann das Benutzer-Steuerelement in Ordnung verwendet werden, aber mit der Referenz bekomme ich nur die Meldung "Fehler beim Laden Toolbox-Element", wenn Sie versuchen, es zu verwenden.
Der native Anruf ist funktional und beeinträchtigt das Benutzersteuerelement in keiner Weise. Das Benutzersteuerelement kann im Designer mit dem enthaltenen DLL-Aufruf problemlos angezeigt werden. Auch wenn das Steuerelement manuell zu einem Formular hinzugefügt und als Programm ausgeführt wird, wird es auch fein angezeigt.
Das lässt mich vermuten, dass das Problem nur darin besteht, dass Visual Studio Designer wissen muss, wo sich diese native DLL befindet. Aber ich bin mir nicht sicher, wie ich es sagen soll oder wo ich die DLL platzieren soll, damit sie es finden kann. Soweit ich weiß, gibt es in den Projekteinstellungen keine Möglichkeit, auf eine native DLL zu verweisen. Es macht also Sinn für mich, dass sich der Designer nur beschwert, weil er es nicht gut machen kann.
Gibt es eine Möglichkeit, dies zum Funktionieren zu bringen?
Leider haben Sie in VS einen "bug by design" gefunden (oder mit anderen Worten, ein "Feature").
Ihr Verdacht, dass das Problem eine Frage des Visual Studio-Designers ist, der wissen muss, wo sich die native DLL befindet, ist teilweise richtig. Es ist keine Frage der Unwissenheit bezüglich des Ortes, sondern eher die Tatsache, dass der Designer nicht über Mixed-Mode-Assemblies (die sowohl verwalteten als auch nativen Code enthalten) nachdenken kann, um die Kontrolle zu instantiieren. Dies führt dazu, dass die Toolbox den von Ihnen notierten Fehler anzeigt.
Die Problemumgehung besteht darin, die C ++ - Quelldateien mithilfe von /clr:pure zu kompilieren, um eine rein verwaltete EXE zu erstellen.
Eine andere Möglichkeit (in VS auch ein "bug by design") ist, dass das Steuerelement, das Sie hinzufügen möchten, als 64-Bit-Komponente kompiliert wurde. Da Visual Studio ein 32-Bit-Prozess ist, kann es nur 32-Bit-Module ausführen. Sie können zwar einen Verweis auf eine 64-Bit-Assembly hinzufügen, diese JIT kann diese 64-Bit-Assembly jedoch nicht JIT kompilieren und im Prozess ausführen.
Die Problemumgehung besteht darin, Ihre Benutzersteuerungsbaugruppe mit der Einstellung "AnyCPU" zu kompilieren, wodurch sie als 32-Bit-Prozess in einer 32-Bit-Umgebung und als 64-Bit-Prozess in einer 64-Bit-Umgebung ausgeführt wird Umgebung. Wirklich, das ist das Beste aus beiden Welten, vorausgesetzt, Sie haben Ihren Code richtig geschrieben.
Wenn keiner von denen funktioniert, gibt es immer die Möglichkeit, den Designer zu umgehen. Sie können weiterhin den erforderlichen Code schreiben, um Ihr Benutzersteuerelement zu instanziieren und seine Eigenschaften in dem Initialisierer des Formulars festzulegen. Alles, was Sie verlieren würden, ist die Möglichkeit, das Steuerelement innerhalb des Designers in Visual Studio zu verwenden. Alles würde zur Laufzeit wie erwartet funktionieren.
Verknüpfen Sie Ihre Bibliothek mit der Option /DELAYLOAD:"y_native.dll ". Dies löste das gleiche Problem für mich.
Ich fand das, das wie ein ähnliches Problem aussieht?
MS scheint also offiziell eine Umstellung von VS2008 auf VS2010 als Workaround zu sagen.
Haben Sie jemals eine andere Problemumgehung gefunden?
Dies ist ein Problem, das ich gerade in VS2008 mit einem C # .net-verwalteten Projekt unter Verwendung eines verwalteten C ++ - Wrapper-Projekts mit einem nicht verwalteten C ++ - Projekt erfahre.
Es sieht für mich sicher so aus, als wären die temporären Designer-Assemblies, die Visual Studio verwendet, ein Problem - es lädt die erkannte Abhängigkeitswrapper-Assembly in den temporären Ordner, aber nicht die nicht verwalteten Abhängigkeiten dieser Wrapper-Assembly. Ich kann sehen, dass dies in C: \ Users \ Benutzername \ AppData \ Local \ Microsoft \ VisualStudio \ 9.0 \ ProjectAssemblies ist. Wenn ich versuche, den Designer zu laden, wird dort ein neuer Ordner mit der darin enthaltenen verwalteten DLL erstellt, nicht jedoch die nicht verwalteten Abhängigkeiten. Leider kann ich nicht verstehen, was die Person in der Frage vom Microsoft-Link oben sagt, ist die Problemumgehung mit $ (TargetDir).
Es scheint mir, dass die Kontrolle mit dem Verweis auf die native DLL fehlschlägt, weil Visual Studio sie nicht laden kann. Versuchen Sie, PATH-Umgebungsvariable entweder global oder für ausführbare Visual Studio-Dateien festzulegen, wenn Sie sie ausführen. Wenn das nicht hilft, versuchen Sie, das Entwurfszeitverhalten Ihres Steuerelements zu debuggen, und Sie sollten das Problem finden können.
Ich hatte ein Problem ähnlich dem, das vielleicht das gleiche ist wie Ihres (wer weiß, wie viele Dinge das verursachen könnten?), im Grunde, dass ich die Steuerungen nicht an einen Designer absetzen konnte, aber die vorhandenen Steuerelemente funktionierten gut sowohl Produktion als auch Test.
Zur Erinnerung, hier war meine Lösung:
1) Ändern Sie Ihre Lösungseinstellungen auf x86. So konnte ich dem Designer die Kontrolle geben, ihn bewegen usw. 2) Wenn Sie fertig sind, können Sie zurück zu AnyCPU oder x64 wechseln. Ich benutze den Designer wirklich nur, um das Setzen einiger Werte zu vereinfachen, und es scheint, dass das ganze 32/64 Bit Ding Probleme verursacht.
Tags und Links dll visual-studio user-controls designer c++-cli