Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Anmärkning
Det här avsnittet refererar till förhandsversionen av .NET Native Developer, som är en förhandsversion av programvara. Du kan ladda ned förhandsversionen från Microsoft Connect-webbplats (kräver registrering).
Alla metadatasökningsfel i appar som utvecklats med hjälp av den interna verktygskedjan .NET resulterar inte i ett undantag. Vissa kan manifesteras på oförutsägbara sätt i en app. I följande exempel visas en åtkomstöverträdelse som orsakas av att referera till ett null-objekt:
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]
Nu ska vi försöka felsöka det här undantaget med hjälp av den trestegsmetod som beskrivs i avsnittet "Åtgärda saknade metadata manuellt" i Komma igång.
Vad gjorde appen?
Det första att notera är async nyckelord maskiner vid basen av stacken. Det kan vara problematiskt att avgöra vad appen verkligen gjorde i en async-metod, eftersom stacken har förlorat kontexten för det ursprungliga anropet och har kört async-koden på en annan tråd. Vi kan dock dra slutsatsen att appen försöker läsa in sin första sida. I implementeringen för NavigationArgs.Setuporsakade följande kod åtkomstöverträdelsen:
AppViewModel.Current.LayoutVM.PageMap
I det här fallet var egenskapen LayoutVM på AppViewModel.Currentnull. Brist på metadata orsakade en subtil beteendeskillnad och resulterade i att en egenskap var oinitierad istället för att anges, som appen förväntade sig. Genom att sätta en brytpunkt i koden där LayoutVM borde ha initierats kan det ge insikt i situationen. Observera dock att typen på LayoutVMär App.Core.ViewModels.Layout.LayoutApplicationVM. Det enda metadatadirektivet som hittills finns i filen rd.xml är:
<Namespace Name="App.ViewModels" Browse="Required Public" Dynamic="Required Public" />
En sannolik kandidat för felet är att App.Core.ViewModels.Layout.LayoutApplicationVM saknar metadata eftersom det finns i ett annat namnområde.
I det här fallet löstes problemet genom att lägga till ett körningsdirektiv för App.Core.ViewModels. Rotorsaken var ett API-anrop till metoden Type.GetType(String) som returnerade null-och appen ignorerade problemet tyst tills en krasch inträffade.
I dynamisk programmering är det en bra praxis vid användning av reflektions-API:er under .NET Native att använda Type.GetType-överlagringar som utlöser ett undantag vid fel.
Är det här ett isolerat fall?
Andra problem kan också uppstå när du använder App.Core.ViewModels. Du måste bestämma om det är värt att identifiera och åtgärda varje undantag för metadata som saknas, eller spara tid och lägga till direktiv för en större klass av typer. Här kan det vara bäst att lägga till dynamic metadata för App.Core.ViewModels om den resulterande storleksökningen av utdatabinärfilen inte är ett problem.
Kan koden skrivas om?
Om appen hade använt typeof(LayoutApplicationVM) i stället för Type.GetType("LayoutApplicationVM")kunde verktygskedjan ha bevarat browse metadata. Det skulle dock fortfarande inte ha skapat invoke metadata, vilket skulle ha lett till ett MissingMetadataException undantag när typen instansierades. För att förhindra undantaget måste du fortfarande lägga till ett körningsdirektiv för namnområdet eller den typ som anger dynamic princip. Information om körningsdirektiv finns i Runtime-direktiv (rd.xml) Konfigurationsfilreferens.