4

XAML エラーをデバッグするための一般的な方法/アプローチを探しています。通常、C# のエラーはかなり簡単に調べることができ、情報を見つけるのに十分具体的です。ただし、XAML は一般的なXAML Parsing failedエラーをスローするように見えます。

ここに画像の説明を入力

これらのエラーにアプローチし、スローされるエラーに役立つ可能性のあるファイル、行番号、またはその他の情報を絞り込む一般化された方法を探しています。

4

3 に答える 3

3

これは、明確でない場合に XAML エラーの原因となっているファイルを特定するために使用するきちんとした方法です...

リソース ディクショナリを含むすべての XAML ファイルを 1 つずつ開き、開始ルート要素の後に空白を追加します。ファイルが見つかった行番号が 1 つ増えると、デバッガーで障害が発生するまで再度実行します。

誰もこの行動を正当化することはできません。フレームワークリソースの読み込みメソッドがストリームで呼び出されることしか想像できないので、読み取っているファイルの名前が何であるかはわかりません。その中の位置だけです。

改善する必要があります。リソース読み込みメソッドを呼び出すフレームワークの部分は、デバッグ メッセージを発行するか、何らかのコンテキストで名前を渡す必要があります。これにより、フレームワークの下部が適切なエラー メッセージを発行できるようになります。

于 2012-10-20T18:59:02.230 に答える
1

注: 移動してさらに学習するにつれて、これを拡張する予定です。この回答に貢献したい場合は、これを CW に変更します。それまでの間、適切と思われる変更を自由に行ってください。

変更が小さい == 範囲が限定されたエラーが小さい

一般に、@DenDelimarsky が述べたように、小さな変更を加えてコードを実行/デバッグすることは良いスタートです。これにより、ほとんどの場合、エラーの範囲を作業中の領域だけに絞り込むことができます.

ただし、問題を絞り込むために使用できるその他のヒントを次に示します。

クラスを検索:

例外の特定のメッセージには、次のようにe記載されています。

プロパティ 'Windows.UI.XAML への割り当てに失敗しました。ResourceDictionary .Source' (強調を追加)

これは、クラスResourceDicionaryにプロパティの割り当てが複雑であることを意味しますSource。最初に編集したファイルの範囲内で検索を実行し、エラーが見つからない場合は、このクラスのソリューション全体で検索を実行し、存在する可能性のあるエラーを探します。

于 2012-10-15T21:00:30.910 に答える
0

実際に表示されているのは、XAML エラーを処理する通常の方法です。それ以上に、実際には StandardStyles の外で問題が発生しています。さらに、XAML を変更した後、通常のデバッグ方法に従って頻繁にデバッグを行うと、問題を絞り込むのは通常かなり簡単です。

于 2012-10-15T20:16:23.137 に答える