顯然，VS在一個cmd文件中包含事件後和預生成事件，它會在LocalSettings/Temp文件夾中彈出。卡巴斯基突然（它昨天工作正常）認定這是一種威脅（RootShell風險），並將它們放在隔離區中，這使我留下了一個掛起的VS，並且沒有辦法編譯項目（除了全部手動刪除事件）。卡巴斯基在我的前期/後期構建事件中窒息
SysAdmin在這裏是 - 可以理解的 - 不喜歡在LocalSettings/Temp文件夾中爲*.TMP.EXEC.CMD文件做通配符異常。到目前爲止，我的Google-fu並沒有幫到我。
任何人遇到此問題或有任何提示？
編輯 FWIW，與git，SmartGit和其他程序的負載有同樣的問題。卡巴斯基獲得以智能爲自己的好...
等待，你的公司自己的IT策略阻止您讓您的工作？
@格雷格：它的痛苦，我看到這種心態在技術答案的幌子延續。我們應該鼓勵與您的系統管理員合作，而不是針對他們。很可能，這只是卡巴斯基默認設置的結果，再加上Visual Studio稍微奇怪的做法，現在系統管理員意識到，他們正試圖找到一個可行的解決方案。
也就是說，如果您的系統管理員沒有積極尋找替代解決方案，那麼他們並沒有正確地開展工作。這是一個可報告的問題。當然，你的辦公室的政治將嚴重影響開發者vs系統管理員的勝利 - 甚至當系統管理員的股票「公司安全」卡被玩時，一些上級會變得恐慌！
作爲一個系統管理員，我也難受的任意允許*.tmp.exec.cmd文件執行選中 - Local Settings\Temp是非常容易寫，從許多地方和許多（插入知名軟件）漏洞可以允許執行。
這就是說，作爲一名開發人員，我最近也遇到了同樣的問題，並希望看到解決方案。因此，通過兩個帽子（以及一些Google搜索），我查看了與客戶端計算機相關的卡巴斯基策略/事件，並可以看到生成事件批處理文件在應用程序活動分析器中觸發Input/Output redirection規則。所以我想這是Visual Studio捕獲構建事件輸出的方式的一個問題。
以下大部分內容都將成爲我試圖解決此問題的成果，並取得不同程度的成功。我還在幾臺獨立的機器上運行CruiseControl.NET（這是我第一次注意到這個問題的地方），所以我將在一條切線上分解以涵蓋這些機器。
我相信最近的一次卡巴斯基更新可能已經改變了默認操作，從允許/提示到隔離，或者現在的定義過於熱情了。
卡巴斯基文檔可能會有點亮（最好），特別是關於主動防禦組件以及它實際檢查的內容。
我可以看到四種可能的解決方案，這一點，除了上述的通配符排除：
*.tmp.exec.cmd但限制它僅針對不受威脅類型的主動防禦組件RootShell%WINDIR%\Microsoft.NET\Framework\*\MSBuild.exe，（和Framework64）與Do not restrict application activity選項＃1可能就足夠了，因爲它把控制與最終用戶（如果他們被認爲是可靠的，足以作出決定），但可能會鎖定在CC.NET構建過程，同時等待響應。
選項＃2可能會提供足夠的邊緣情況，以至於sysadmin更適合包含該規則。您也可以使用臨時路徑來限定規則，例如%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，運行卡巴斯基服務器版（不包括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設備添加到不同的KAV組，從而放寬AAA限制。
我希望這會有所幫助（實際上，我希望別人會出現並說「你錯過了一些非常簡單的東西」，然後解釋它是什麼!!）。是我在KAV發現，以防止或減少這種效果的選項如下：DR版本;
TL。讓您的系統管理員要挑一個自己最熟悉的：
%COMSPEC%到受信任的應用程序的策略的列表中，選中「不控制程序活動」%TEMP%\*.tmp.exec.cmd到策略的排除規則，使用威脅類型RootShell和組件Proactive Defense我的偏好是＃4;其他人可能不同。
等等，貴公司自己的IT政策阻止你完成工作？拿起你的老闆。這類事情不是一個編程問題。 – 2010-12-02 07:13:06
@Greg，是的，我知道這是一個輕微的話題，我猶豫是否問服務器故障，但它可能不是一個編程問題，這對程序員來說是一個問題。 – Benjol 2010-12-02 07:24:17