注
このトピックでは、プレリリース ソフトウェアである .NET Native Developer Preview について説明します。 プレビューは、Microsoft Connect Web サイトからダウンロードできます (登録が必要)。
.NET ネイティブ ツール チェーンを使用して開発されたアプリのすべてのメタデータ参照エラーで例外が発生するわけではありません。 一部のアプリでは、予期しない方法で表示される場合があります。 次の例は、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]
「Getting Started」の「不足しているメタデータを手動で解決する」セクションで説明されている3段階のアプローチを使用して、この例外のトラブルシューティングを試みましょう。
アプリは何をしていましたか?
最初に注意すべき点は、スタックのベースにある async キーワードの機構です。 スタックが元の呼び出しのコンテキストを失い、別のスレッドでasyncコードを実行しているため、async メソッドでアプリが実際に何を行っていたかを判断すると、問題が発生する可能性があります。 ただし、アプリが最初のページを読み込もうとしていることを推測できます。
NavigationArgs.Setupの実装では、次のコードによってアクセス違反が発生しました。
AppViewModel.Current.LayoutVM.PageMap
このインスタンスでは、LayoutVMのAppViewModel.Current プロパティは null でした。 メタデータが一部欠如しているために動作が微細に異なり、アプリが期待していたプロパティがセットされず、初期化されないままとなりました。
LayoutVM初期化する必要があるコードにブレークポイントを設定すると、状況が明るくなります。 ただし、 LayoutVMの型は App.Core.ViewModels.Layout.LayoutApplicationVMされることに注意してください。 rd.xml ファイルにこれまでに存在する唯一のメタデータ ディレクティブは次のとおりです。
<Namespace Name="App.ViewModels" Browse="Required Public" Dynamic="Required Public" />
エラーの可能性が高い原因は、 App.Core.ViewModels.Layout.LayoutApplicationVM が別の名前空間にあるため、メタデータが不足していることです。
この場合、 App.Core.ViewModels のランタイム ディレクティブを追加すると、問題が解決されました。 根本原因はType.GetType(String) を返した メソッドへの API 呼び出しであり、クラッシュが発生するまでアプリは問題を警告なく無視しました。
動的プログラミングでは、.NET Native でリフレクション API を使用する場合は、エラー時に例外をスローする Type.GetType オーバーロードを使用することをお勧めします。
これは分離されたケースですか?
App.Core.ViewModelsを使用すると、他の問題も発生する可能性があります。 不足している各メタデータ例外を特定して修正するか、時間を節約し、より大きな型のクラスのディレクティブを追加する価値があるかどうかを決定する必要があります。 出力バイナリのサイズ増加が問題でない場合、dynamic に対する App.Core.ViewModels メタデータを追加するのが最良のアプローチかもしれません。
コードは書き換えられますか?
アプリがtypeof(LayoutApplicationVM)ではなくType.GetType("LayoutApplicationVM")を使用していた場合、ツール チェーンはメタデータbrowse保持している可能性があります。 ただし、 invoke メタデータはまだ作成されていないため、型をインスタンス化するときに MissingMetadataException 例外が発生する可能性があります。 例外を回避するには、名前空間または dynamic ポリシーを指定する型のランタイム ディレクティブを追加する必要があります。 ランタイム ディレクティブの詳細については、「 ランタイム ディレクティブ (rd.xml) 構成ファイル リファレンス」を参照してください。