SharePoint 中的信息管理策略
这是一个晦涩难懂的难题，但它让我彻底发疯：
我正在 MOSS 中创建自定义信息管理策略。 我已经实现了 IPolicyFeature，并且我的策略功能很高兴通过配置新的 SPItemEventReceiver 来注册自身。 我的图书馆中的所有新项目都会按其应有的方式触发事件，并且一切正常。
IPolicyFeature 还有一个 ProcessListItem 方法，该方法应该追溯地将策略应用于库中已有的项目（至少，只要它不断返回 true 就应该这样做）。 但事实并非如此。 它仅将该策略应用于库中的第一个项目，我完全不知道为什么。
它似乎没有抛出异常，并且它确实从处理第一项返回 true，我想不出还有什么可看的。 任何人？
编辑：下面科里的回答让我走上了正确的道路。 其他东西确实失败了——我不知道是什么，因为我的 Windbg-fu 不是它应该的样子，但我怀疑它类似于“在迭代时修改集合”。 我的代码修改了传递给 ProcessListItem 的 SPListItem，然后对其调用 SystemUpdate； 一旦我更改了代码，以便它创建了自己的变量（指向完全相同的 SPListItem）并使用它，问题就消失了......
An obscure puzzle, but it's driving me absolutely nuts:
I'm creating a custom Information Management Policy in MOSS. I've implemented IPolicyFeature, and my policy feature happily registers itself by configuring a new SPItemEventReceiver. All new items in my library fire the events as they should, and it all works fine.
IPolicyFeature also has a method ProcessListItem, which is supposed to retroactively apply the policy to items that were already in the library (at least, it's supposed to do that for as long as it keeps returning true). Except it doesn't. It only applies the policy to the first item in the library, and I have absolutely no idea why.
It doesn't seem to be throwing an exception, and it really does return true from processing that first item, and I can't think what else to look at. Anyone?
Edit: Cory's answer, below, set me on the right track. Something else was indeed failing -- I didn't find out what, since my windbg-fu isn't what it should be, but I suspect it was something like "modifying a collection while it's being iterated over". My code was modifying the SPListItem that's passed into ProcessListItem, and then calling SystemUpdate on it; as soon as I changed the code so that it created its own variable (pointing at the exact same SPListItem) and used that, the problem went away...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我能想到的只有几件事可以尝试。 首先，您是否在可以使用 Visual Studio 进行调试的机器上进行开发？ 所以只要逐步完成它即可。
假设情况并非如此 - 我要做的是在注册策略之前启动 WinDBG 并将其附加到进程。 打开第一次机会异常，以便在异常发生时它会中断。 您可以通过在破解后发出命令“sxe clr”来完成此操作。以下是有关 WinDBG 的更多信息：
http://blogs.msdn。 com/tess/archive/2008/06/05/setting-net-breakpoints-in-windbg-for-applications-that-crash-on-startup.aspx
我要做的就是观察第一次机会抛出异常，并执行 !PrintException 来查看发生了什么。 我的猜测是，某个地方抛出了异常，导致应用程序停止处理其他项目。
ProcessListItem 的逻辑是什么样的？ 您是否尝试过仅返回 true 以确保其有效？
There's only a couple of things I can think of to try. First, are you developing on the box where you might be able to use Visual Studio to debug? So just stepping through it.
Assuming that's not the case - what I'd do is fire up WinDBG and attach it to the process just before I registered the policy. Turn on first chance exceptions so that it breaks whenever they occur. you can do that by issuing the command "sxe clr" once it is broken in. Here's a little more info about WinDBG:
http://blogs.msdn.com/tess/archive/2008/06/05/setting-net-breakpoints-in-windbg-for-applications-that-crash-on-startup.aspx
What I'd do is then watch for First Chance exceptions to be thrown, and do a !PrintException to see what is going on. My guess is that there is an exception being thrown somewhere that is causing the app to stop processing the other items.
What does the logic look like for your ProcessListItem? Have you tried just doing a return true to make sure it works?
有一些不错的想法，谢谢。 Visual Studio 调试器没有显示异常（并且我已将所有内容包装在 try/catch 块中以防万一），但我没有想过尝试 Windbg...
Some nice ideas there, thanks. The Visual Studio debugger wasn't showing an exception (and I've wrapped everything in try/catch blocks just in case), but I hadn't thought of trying Windbg...