TFS 2010：WorkItem.Save 再次触发 WorkItemChangedEvent答案

【问题标题】：TFS 2010: WorkItem.Save triggers WorkItemChangedEvent againTFS 2010：WorkItem.Save 再次触发 WorkItemChangedEvent
【发布时间】：2014-07-17 21:56:57
【问题描述】：

我最好先解释一下我正在尝试做的事情的高级概述（以防万一我要解决这个可怕的错误）：在 TFS 中，我们有一个包含“优先级”的“故事”工作项“ 场地。在任何给定时间，我们可能有 20-30 个具有优先级的故事。例如，我们可能有 20 个完全优先的故事（1 到 20），然后想要创建一个应该是我们新的首要任务的新故事。所以，我希望能够给它优先级 1，然后有一个服务器端插件，它将更新所有其他故事的优先级，这样我最终得到 1 到 21（1 是我们的新故事）刚刚创建）。

为此，我为 TFS 2010 创建了一个订阅 WorkItemChangedEvent 的服务器端插件。判断优先级是否已更新是足够聪明的，因此在这种情况下它只会更改工作项。我遇到的问题是，如果我改变优先级并运行WorkItem.Save()，它会再次触发WorkItemChangedEvent，并且优先级发生了变化，所以逻辑为真，它会再次更新并保存。

之前，我创建了一个服务器端插件，将其中一个日期时间字段的时间更新为 00:00:00（如果它还不是 00:00:00）并注意到了这种行为。这不是太大的问题，因为在第二次运行时，什么都不会发生，因为时间已经是 00:00:00。但是在这种尝试更新一大堆工作项的优先级的情况下，它是一个交易破坏者。有没有办法阻止 WorkItem.Save() 触发 WorkItemChangedEvent？也许另一种方法可以完全做到这一点？

【问题讨论】：

标签： tfs event-handling

【解决方案1】：

我知道解决此问题的最简单方法是添加特定评论，然后检查工作项的评论/历史项目，以查看您上次更新它作为您所做更改的一部分。

另外，请查看以下post for pointers on how to create your service so that it remains stable。

【讨论】：

如果没有人提出更好的解决方案，我会将其标记为答案。它会起作用，但如果没有更清洁的方法，那就太糟糕了。
当然我也希望有更好的解决方案。也许你可以在 tfs 聚合器tfsaggregator.codeplex.com的源代码中找到一些东西@
出于时间考虑，我最终选择了这条路线。我必须在更新优先级字段和布尔字段的地方进行一次保存，然后处理程序可以忽略布尔值为真的任何情况。然后我进行了第二次保存，将布尔值设置为 false。在那种情况下，优先级并没有改变，所以再一次，什么也没有发生。
害怕这将是唯一的答案。这也是微软如何在构建中使用 _NOCI_ 来防止在提交后触发另一个自动构建的方式。

【解决方案2】：

我在自己的扩展程序中通过检查更改者身份是否是服务身份解决了这个问题。如果是，则跳过逻辑。

这似乎是一个比标记数据更优雅的解决方案。

var workItemChangedArgs = notificationEventArgs as WorkItemChangedEvent;
var identityService = requestContext.GetService<IdentityService>();
var changerIdentity = identityService.ReadIdentities(
    requestContext,
    new List<IdentityDescriptor> {
        IdentityHelper.CreateDescriptorFromSid(workItemChangedArgs.ChangerSid)
    },
    QueryMembership.Expanded,
    null).Single();
if (!IdentityHelper.IsServiceIdentity(requestContext, changerIdentity)) {
    // Do stuff….
}

【讨论】：

是的，这听起来是个好主意。坦率地说，我很难相信我没有考虑到它（这是很久以前的事了，我的记忆很模糊），我想知道我是否遇到了某种问题或陷阱......我会有重新审视代码，看看我是否可以按照你的描述重构它。