SharePoint の情報管理ポリシー

Question

難解なパズルだけど、本当に頭がおかしくなってしまいました:

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

IPolicyFeature には、ProcessListItem メソッドもあります。これは、既にライブラリに存在する項目にポリシーを遡及的に適用することになっています (少なくとも、返され続ける限り、これを実行することになっています) true）。そうではないことを除いて。ポリシーを適用するのは、 初め 図書館にあるのですが、その理由がまったくわかりません。

例外をスローしているようには見えません。最初の項目の処理から実際に true を返します。他に何を調べればよいのか考えられません。誰でも？

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

Answer 1

試してみることができることはいくつかあります。まず、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 を実行して、それが機能することを確認してみましたか?

Answer 2

素敵なアイデアがありました、ありがとう。Visual Studio デバッガーには例外は表示されませんでしたが (念のため、すべてを try/catch ブロックで囲みました)、Windbg を試してみようとは思いませんでした...