等等，您公司自己的 IT 政策阻止您完成工作？
@Greg：看到这种心态以技术答案的名义持续存在，我感到很痛苦。我们应该鼓励与您的系统管理员合作，而不是反对他们。这很可能只是 Kaspersky 中的默认设置的结果，再加上 Visual Studio 的一个稍微奇怪的做法，现在系统管理员意识到，他们正在尝试找到一个可行的解决方案。
也就是说，在摒弃通配符的想法之后，如果您的系统管理员没有积极寻找替代解决方案，那么他们就没有正确地完成他们的工作。这是一个需要报告的问题。当然，在开发人员与系统管理员的争论中，你办公室的政治将在很大程度上影响谁获胜——即使是一些高层在系统管理员的股票“公司安全”牌被打出时也会感到恐慌！
作为一名系统管理员，我也对任意允许*.tmp.exec.cmd 文件未经检查地执行感到不舒服——Local Settings\Temp 非常容易从许多地方和大量（插入知名软件) 漏洞利用可以允许执行。
也就是说，作为一名开发人员，我最近也遇到了同样的问题，并希望看到解决方案。
因此，戴上两顶帽子（还有一点谷歌搜索），我查看了与我们的客户端计算机相关的卡巴斯基策略/事件，可以看到构建事件批处理文件正在触发应用程序活动中的 Input/Output redirection 规则分析仪。所以我猜这是 Visual Studio 捕获构建事件输出的方式的问题。
以下大部分内容将是我为解决此问题所做的一些脑筋急转弯，并取得了不同程度的成功。我还在几台单独的构建机器上运行 CruiseControl.NET（这是我第一次注意到这个问题的地方），所以我也将中断讨论这些问题。
我认为最近的卡巴斯基更新可能已将默认操作从允许/提示更改为隔离，或者现在对此的定义过于热心。
卡巴斯基文档可能有点简单（充其量），尤其是关于主动防御组件及其实际检查的内容。
除了前面提到的通配符排除之外，我可以看到四种可能的解决方案：
- 在 Kaspersky 中更改 AAA 设置以使 I/O 重定向成为可提示的活动
- 为
*.tmp.exec.cmd 添加排除规则，但仅限于不受威胁类型RootShell 的主动防御组件的约束
- 关闭 I/O 重定向检查
- 使用
Do not restrict application activity 为%WINDIR%\Microsoft.NET\Framework\*\MSBuild.exe（和Framework64）添加“受信任区域”排除项
选项 #1 可能就足够了，因为它将控制权交给最终用户（如果他们被认为足够可靠以做出决定），但可能会在等待响应时锁定 CC.NET 构建过程。
选项 #2 可能会提供足够多的边缘情况，使系统管理员更愿意包含该规则。您还可以使用临时路径（例如 %TEMP%\*.tmp.exec.cmd）来限定规则，以进一步减少问题。对于服务会话，似乎没有加载环境变量（至少似乎没有触发规则），因此您必须通过在已知域服务帐户下运行 CC.NET 来解决此问题并添加另一个明确指定其临时位置的规则。
选项#3 的味道与通配符异常一样多，如果不是更糟的话。虽然，I/O 重定向真的有那么大吗？将一个进程的输出通过管道传输到另一个进程的能力是否应该受到严格控制？卡巴斯基似乎是这么认为的，但我不太确定。肯定有很多自动化/调度器风格的应用会因此受到不利影响吗？
选项#4 是我作为系统管理员的偏好。如果我能找到正确的设置组合，以便允许 MSBuild 完成其工作，但仍然涵盖其他所有内容，那一定是正确的方法，对吧？
很遗憾，没有，因为 MSBuild.exe 进程会生成一个 cmd.exe 进程来运行 *.tmp.exec.cmd 文件，并且卡巴斯基正是在该 cmd.exe 进程的上下文中扫描文件。这意味着必须为 cmd.exe 定义受信任的应用程序规则，并使用 Do not control application activity。这似乎比*.tmp.exec.cmd 的通配符排除更糟糕，因为这实际上意味着所有批处理文件都被排除在测试之外，而不仅仅是子集。
所以我回到选项#1 和#2 的组合。我为%TEMP%\*.tmp.Exec.cmd、%USERPROFILE%\Local Settings\Temp\*.tmp.Exec.cmd 和%USERPROFILE%\AppData\Local\Temp\*.tmp.Exec.cmd 添加了排除规则（如果未定义%TEMP%，则基于%USERPROFILE% 的路径应该分别在XP 和W7 上到达那里）。我还将I/O redirection 的默认操作更改为Prompt，因此，如果它是一个过于激进的新规则/定义，那么这可能影响的任何其他程序都可以由我的最终用户明确控制（或者，至少，它可能会吓到他们来问我）。
就 CC.NET 而言，计划有两个方面：要么我在实际服务器上安装 CC.NET，运行 Kaspersky Server Edition（不包括 AAA 模块），要么我故意安装 CC。 NET 到工作站构建（例如，如果我想使用单元测试自动查看我的应用程序是否在 W2K/WXP/W7 中工作等），我将其作为标准操作过程的一部分，以配置 CC.NET 服务以在我的专用域服务帐户svc-ccnet，然后将固定排除规则添加到我们的卡巴斯基策略C:\Documents and Settings\svc-ccnet\Local Settings\Temp\*.tmp.Exec.cmd 和C:\Users\svc-ccnet\AppData\Local\Temp\*.tmp.Exec.cmd，威胁类型为RootShell，组件设置为Proactive Defense。在推送中，我可能会将 CC.NET 设备添加到放宽 AAA 限制的不同 KAV 组。
我希望这会有所帮助（实际上，我希望其他人出现并说“你错过了一些非常简单的东西”，然后解释那是什么！！）。
TL;DR 版本：我在 KAV 中找到的用于防止或减少这种影响的选项如下。让您的系统管理员选择他们最喜欢的一个：
- 在策略的应用程序活动分析器设置中将 I/O 重定向操作设置为允许或提示
- 在策略的应用程序活动分析器设置中取消选中 I/O 重定向选项
- 将
%COMSPEC% 添加到策略的受信任应用程序列表中，选中“不控制应用程序活动”
- 将
%TEMP%\*.tmp.exec.cmd 添加到策略的排除规则，使用威胁类型RootShell 和组件Proactive Defense
我的偏好是#4；其他人可能会有所不同。