Przykład: Rozwiązywanie problemów z programowaniem dynamicznym

Nie wszystkie błędy wyszukiwania metadanych w aplikacjach opracowanych przy użyciu łańcucha narzędzi .NET Native powodują wyjątek. Niektóre mogą manifestować się w nieprzewidywalny sposób w aplikacji. W poniższym przykładzie pokazano naruszenie dostępu spowodowane odwoływaniem się do obiektu o wartości null:

Access violation - code c0000005 (first chance)
App!$3_App::Core::Util::NavigationArgs.Setup
App!$3_App::Core::Util::NavigationArgs..ctor
App!$0_App::Gibbon::Util::DesktopNavigationArgs..ctor
App!$0_App::ViewModels::DesktopAppVM.NavigateToPage
App!$3_App::Core::ViewModels::AppViewModel.NavigateToFirstPage
App!$3_App::Core::ViewModels::AppViewModel::<HandleLaunch>d__a.MoveNext
App!$43_System::Runtime::CompilerServices::AsyncMethodBuilderCore.CallMoveNext
App!System::Action.InvokeClosedStaticThunk
App!System::Action.Invoke
App!$43_System::Threading::Tasks::AwaitTaskContinuation.InvokeAction
App!$43_System::Threading::SendOrPostCallback.InvokeOpenStaticThunk
[snip]

Spróbujmy rozwiązać ten wyjątek, korzystając z podejścia trzyetapowego opisanego w sekcji "Ręczne rozwiązywanie brakujących metadanych" w temacie Wprowadzenie.

Co robi aplikacja?

Pierwszą rzeczą, którą należy zauważyć, jest mechanizm kluczowy async znajdujący się u podstawy stosu. Określenie, co aplikacja naprawdę robiła w metodzie async, może być problematyczne, ponieważ stos stracił kontekst wywołania źródłowego i uruchomił kod async w innym wątku. Możemy jednak powiedzieć, że aplikacja próbuje załadować swoją pierwszą stronę. W implementacji NavigationArgs.Setup następujący kod spowodował naruszenie dostępu:

AppViewModel.Current.LayoutVM.PageMap

W tym przypadku właściwość LayoutVM na AppViewModel.Current była null. Niektóre brak metadanych spowodowały subtelną różnicę zachowania i spowodowały, że właściwość została niezainicjowana, a nie ustawiona, zgodnie z oczekiwaniami aplikacji. Ustawienie punktu przerwania w kodzie, w miejscu, gdzie LayoutVM powinno było zostać zainicjowane, może rzucić światło na sytuację. Należy jednak pamiętać, że typ LayoutVMjest App.Core.ViewModels.Layout.LayoutApplicationVM. Jedyna dyrektywa metadanych obecna do tej pory w pliku rd.xml to:

<Namespace Name="App.ViewModels" Browse="Required Public" Dynamic="Required Public" />

Prawdopodobną przyczyną niepowodzenia jest brak metadanych w App.Core.ViewModels.Layout.LayoutApplicationVM, ponieważ znajduje się w innej przestrzeni nazw.

W tym przypadku dodanie dyrektywy środowiska uruchomieniowego App.Core.ViewModels rozwiązało problem. Główną przyczyną było wywołanie metody Type.GetType(String) API, która zwróciła null, a aplikacja nie odnotowała problemu do momentu wystąpienia awarii.

W programowaniu dynamicznym dobrym rozwiązaniem w przypadku używania interfejsów API odbicia w programie .NET Native jest użycie przeciążeń Type.GetType, które zgłaszają wyjątek w przypadku awarii.

Czy jest to izolowany przypadek?

Inne problemy mogą również wystąpić podczas korzystania z programu App.Core.ViewModels. Należy zdecydować, czy warto zidentyfikować i naprawić każdy brak wyjątku metadanych, czy zaoszczędzić czas i dodać dyrektywy dla większej klasy typów. W tym miejscu dodanie dynamic metadanych dla App.Core.ViewModels może być najlepszym rozwiązaniem, jeśli wynikowy wzrost rozmiaru pliku binarnego wyjściowego nie jest problemem.

Czy kod może zostać przepisany?

Gdyby aplikacja używała typeof(LayoutApplicationVM) zamiast Type.GetType("LayoutApplicationVM"), łańcuch narzędzi mógł zachować browse metadane. Jednak nadal nie utworzono invoke metadanych, co spowodowałoby wystąpienie wyjątku MissingMetadataException podczas inicjalizacji typu. Aby zapobiec wyjątkowi, nadal należy dodać dyrektywę środowiska uruchomieniowego dla przestrzeni nazw lub typu, która określa politykę dynamic. Aby uzyskać informacje na temat dyrektyw środowiska uruchomieniowego, zobacz Runtime Directives (rd.xml) Configuration File Reference.

Zobacz także

• Pierwsze kroki
• Przykład : Obsługa wyjątków podczas wiązania danych