WPF generuje wyjątek analizy XAML, który zawiera niestandardową kontrolkę Winforms


Mam aplikację WPF, która używa kontrolki niestandardowej Winforms zbudowanej w C ++/CLI. Gdy moja aplikacja przechodzi do analizowania kodu XAML dla mojego głównego okna, zgłasza wyjątek. Informacje wydają się być nieco skrócone, ale mówi:
A first chance exception of type 'System.Windows.Markup.XamlParseException' occurred in PresentationFramework.dllAdditional information: is not a valid Win32 application. (Exception from HRESULT: 0x800700C1) Error in markup file 'OsgViewer;component/osgviewerwin.xaml' Line 1 Position 9.

Skomentowałem moją kontrolkę WinForm w XAML i wszystko ładuje się dobrze. Pomyślałem, że może konstruktor mojej kontrolki robi coś złego, więc umieściłem w nim punkt przerwania, ale punkt przerwania nie wydaje się być włączony podczas uruchamiania aplikacji i nigdy go nie trafia, jak rozumiem, oznacza, że ​​biblioteka DLL zawierający tę linię nie jest ładowany. Co najprawdopodobniej spowoduje zgłoszenie wyjątku podczas tworzenia wystąpienia obiektu typu DLL - nie można znaleźć treści konstruktora obiektu.
Zrobiłem to pomyślnie w innym projekcie w przeszłości, więc wyciągnąłem kolejną niestandardową kontrolkę WinForms z tej aplikacji i utworzyłem ją w XAML i wszystko działa dobrze.
Więc to jest coś w tej bibliotece DLL. Mam odwołanie do biblioteki DLL w mojej aplikacji WPF C #, a kiedy ładuję bibliotekę DLL do Eksploratora obiektów, wszystkie wymagane klasy i przestrzenie nazw są wyświetlane poprawnie. Aplikacja kompiluje się dobrze, problem po prostu pojawia się podczas analizowania kodu XAML. Czy ktoś widział coś takiego? Jakieś pomysły, co może być tego przyczyną? Pomysły na debugowanie? Podziękować!
<Window x:Class="OsgViewer.OsgViewerWin"
xmlns="[url=http://schemas.microsoft.com/winfx/2006/xaml/presentation"]http://schemas.microsoft.com/w ... ot%3B[/url]
xmlns:x="[url=http://schemas.microsoft.com/winfx/2006/xaml"]http://schemas.microsoft.com/winfx/2006/xaml"[/url]
xmlns:int="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"
xmlns:myns="clr-namespace:MyGlobalNS.MyNS;assembly=MyAssembly"...
<int:WindowsFormsHost x:Name="m_Host">
<myns:CMyClass x:Name="m_MyClass"/>
</int:WindowsFormsHost>...
</window>

Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Miałem podobne problemy (ale nie z dokładnie tym samym komunikatem o błędzie). Wygląda na to, że WPF nie może utworzyć wystąpienia niestandardowej kontrolki Winforms.
Wyzwaniem jest dowiedzieć się, dlaczego. Oto moje sugestie, które możesz wypróbować:
  • Sprawdź, czy niezarządzane debugowanie jest włączone (we właściwościach projektu -> debugowanie)
  • Dowiedz się, czy w bibliotece DLL C ++/CLI istnieją zależności, w których zaimplementowano formant Winforms i czy nie można ich rozwiązać. Aby znaleźć zależności od natywnych bibliotek DLL, należy użyć tego narzędzia Dependency Walker (depends.exe) http://www.dependencywalker.com/... .NET Reflector przeanalizuje tylko zależności zarządzane.
  • Skomentuj krok po kroku niestandardową kontrolkę Winform i spróbuj ponownie.
  • Użycie Gflags.exe do włączenia przycisk bootloadera (por. MF. Awarie debugowania http://blogs.msdn.com/junfeng/ ... .aspx LoadLibrary )
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Miałem podobny problem i mój problem polegał na tym, że projekt C # był skonfigurowany do korzystania z dowolnego procesora, podczas gdy projekt C ++ został zbudowany do korzystania z x86. Aby zainstalować oba przypadki użycia x86, problem został rozwiązany
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Widziałem ten problem podczas próby użycia funkcji boost :: thread. Aby obsługiwać lokalną pamięć wątkową, boost :: thread wykonuje wywołanie API Win32, które jest niekompatybilne z aplikacjami CLI. Problem pojawia się, jeśli spróbujesz # Uwzględnić coś z wątków w kodzie CLI.
Rozwiązaniem jest całkowite uniknięcie używania boost :: thread lub ograniczenie jego użycia do plików .cpp w kodzie natywnym.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Czy na pewno masz dll w folderze system32 lub w tym samym folderze z exe? Otrzymałem dokładnie ten sam komunikat o błędzie podczas uruchamiania projektu WPF zbudowanego za pomocą biblioteki CLI dll, gdy dll znajdowała się w innym folderze.
Mikrofon
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Miałem też ten problem i wszystko, co musiałem zrobić, to przejść do właściwości projektu> Bezpieczeństwo i kliknąć To jest aplikacja z pełnym zaufaniem. Uruchomiłem ponownie projekt i udało się!
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Miałem też to stanowisko kierownicze, ale moje rozwiązania zmieniały kolejność elementów w XAML. Użyłem XmlDataProvider i wyświetliłem zawartość w polu listy. Po prostu umieściłem XmlDataProvider przed ListBox.

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się