1

あいまいなパズルですが、それは私を完全に夢中にさせています:

MOSS でカスタムの情報管理ポリシーを作成しています。IPolicyFeature を実装しました。私のポリシー機能は、新しい SPItemEventReceiver を構成することでうまく登録されます。ライブラリ内のすべての新しいアイテムは、必要に応じてイベントを発生させ、すべて正常に動作します。

IPolicyFeature にはメソッド ProcessListItem もあり、これは既にライブラリにあるアイテムにポリシーをさかのぼって適用することになっています (少なくとも、それが を返し続ける限り、それを行うことになっていますtrue)。そうでないことを除いて。ポリシーはライブラリの最初のアイテムにのみ適用されますが、その理由はまったくわかりません。

例外をスローしているようには見えず、最初のアイテムの処理から実際に true が返され、他に何を見ればよいかわかりません。誰？

編集：以下のCoryの答えは、私を正しい軌道に乗せました。他の何かが実際に失敗していました.windbg-fuが本来あるべきものではないため、何が原因かわかりませんでしたが、「反復中にコレクションを変更する」ようなものだったと思います。私のコードは、ProcessListItem に渡された SPListItem を変更し、それに対して SystemUpdate を呼び出していました。コードを変更して独自の変数（まったく同じSPListItemを指す）を作成し、それを使用するとすぐに、問題は解決しました...

4

2 に答える 2

1

試してみようと思うことができるのは2、3だけです。まず、Visual Studio を使用してデバッグできるボックスで開発していますか? だからそれを踏むだけです。

そうではないと仮定すると、ポリシーを登録する直前に、WinDBG を起動してプロセスにアタッチします。初回例外をオンにして、発生するたびに中断するようにします。侵入したら、コマンド「sxe clr」を発行することでそれを行うことができます。WinDBG についての詳細は次のとおりです。

http://blogs.msdn.com/tess/archive/2008/06/05/setting-net-breakpoints-in-windbg-for-applications-that-c​​rash-on-startup.aspx

次に、First Chance 例外がスローされるのを監視し、!PrintException を実行して何が起こっているかを確認します。私の推測では、アプリが他のアイテムの処理を停止する原因となっている例外がスローされている可能性があります。

ProcessListItem のロジックはどのようになりますか? return true を実行して、それが機能することを確認しましたか?

于 2008-09-05T20:11:12.057 に答える
0

そこにいくつかの素晴らしいアイデア、ありがとう。Visual Studio デバッガーは例外を表示していませんでした (念のため、すべてを try/catch ブロックでラップしました) が、Windbg を試すことは考えていませんでした...

于 2008-09-06T09:20:00.400 に答える