Microsoft.Build.Utilities.FileTracker引發異常錯誤。適用於不同的項目

最近在Visual Studio 2010 Ultimate，Win7 64bit的C＃中，編譯任何項目時出現以下錯誤。解決方法是將<TrackFileAccess>false</TrackFileAccess>添加到項目文件。如果我沒有弄錯，這會禁用增量構建，所以我想遠離這個解決方法。Microsoft.Build.Utilities.FileTracker引發異常錯誤。適用於不同的項目

任何人都知道永久可靠的修復程序是什麼？我確實重新安裝了.NET Framework 4和VS 2010.我沒有4.0或更早版本的4.0框架文件夾。

Error 1 The "GenerateResource" task failed unexpectedly. 
System.TypeInitializationException: The type initializer for 'Microsoft.Build.Utilities.FileTracker' threw an exception. ---> System.NullReferenceException: Object reference not set to an instance of an object. 
    at Microsoft.Build.Utilities.FileTracker..cctor() 
    --- End of inner exception stack trace --- 
    at Microsoft.Build.Utilities.FileTracker.ForceOutOfProcTracking(ExecutableType toolType, String dllName, String cancelEventName) 
    at Microsoft.Build.Tasks.GenerateResource.Execute() 
    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() 
    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext

來源

2010-07-11 Tony_Henrich

我發現我的環境解決方案通過反映Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Build.Utilities.v4.0.dll

我的TEMP/TMP環境變量指向沒有任何進一步目錄嵌套的RAM驅動器根文件夾（T：\）！ line s_tempPath = Path.GetDirectoryName（Path.GetTempPath（））;在Microsoft.Build.Utilities.FileTracker的靜態ctor中導致null，導致您提到的異常。

現在我的TEMP/TMP環境變量指向T：\ TEMP並且一切正常。

來源

2010-07-28 12:16:10 Harald

優秀的偵探！我有這個相同的問題。我在Reflector中打開了DLL，並且當我看到您的帖子時，也開始瀏覽FileTracker類。 – JustinB 2010-09-09 23:49:25

感謝您的解決方案。一小部分：有時在這個異常之後MSBuild.exe卡住了（甚至在關閉devenv.exe之後）。他們應該被殺害，以解決問題 – 2012-05-31 08:23:39

近7年後，這個解決方案仍然適用於Visual Studio 2013 Community Edition更新4 .. Sheesh。謝謝！ – 2017-03-30 08:20:54

此解決方法是從MS forums：

編輯您的項目文件，將其添加到第一的PropertyGroup：
<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies> 

來源

2010-07-11 02:22:32

它沒有幫助。這篇文章中提到的問題似乎是另一回事。 – 2010-07-11 07:01:31

這個問題有可能是註冊表清理造成的，比如CCleaner 3.x版本，我執行它後，VS2010開始拋出這個文件跟蹤器問題，我敢肯定這不是由其他操作引起的。

解決方法：我檢查了文件是否退出或不在C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319裏面，Filetracker還在，然後我檢查是否有多個4.0.xxx文件夾退出？答案是否定的。

因此，我確認這不是VS問題，它是由於不正確的清理過程導致的註冊表損壞。

下載完整版.net 4.0框架並重新安裝，選擇修復。重新啓動電腦，現在你的VS應該現在工作。

我的觀點是，既然在發生此事件之前，您也不會對通用目標文件進行任何修改。

來源

2011-06-10 05:29:16 Jayoscar

老問題，但我希望它會幫助Google的人。它不完全是原始問題中的Nullref，它是由Microsoft跟蹤的錯誤引起的，但我想分享它。

我在構建C++項目時遇到了嚴重的問題，我追蹤到這些項目是由Temp環境變量（可以在路徑名中包含空格）引起的。

Unerwarteter Fehler bei der CL-Aufgabe. 
System.TypeInitializationException: Der Typeninitialisierer für "Microsoft.Build.Utilities.FileTracker" hat eine Ausnahme verursacht. ---> System.IO.FileNotFoundException: Das System kann die angegebene Datei nicht finden. (Ausnahme von HRESULT: 0x80070002) 
    bei System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo) 
    bei System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode) 
    bei Microsoft.Build.Shared.NativeMethodsShared.ThrowExceptionForErrorCode(Int32 errorCode) 
    bei Microsoft.Build.Shared.NativeMethodsShared.GetLongFilePath(String path) 
    bei Microsoft.Build.Utilities.FileTracker..cctor() 
    --- Ende der internen Ausnahmestapelüberwachung --- 
    bei Microsoft.Build.CPPTasks.CL.ComputeOutOfDateSources() 
    bei Microsoft.Build.CPPTasks.TrackedVCToolTask.SkipTaskExecution() 
    bei Microsoft.Build.Utilities.ToolTask.Execute() 
    bei Microsoft.Build.CPPTasks.TrackedVCToolTask.Execute() 
    bei Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() 
    bei Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__20.MoveNext()

更改TEMP和TMP到：

%USERPROFILE%\Appdata\Local\Temp

解決它。

來源

2013-07-29 14:24:53 BlueM

請注意，'C：\ Users \ David \ Local Settings \ Temp'與'C：\ Users \ David \ AppData \ Local \ Temp'不一樣。雖然他們可能通過聯結鏈接到相同的地方，但可以給出錯誤的BlueM提及，其他人可以正確使用（提示：BlueM列出的是正確的答案）。 – 2014-06-17 06:42:43

Microsoft.Build.Utilities.FileTracker引發異常錯誤。適用於不同的項目

回答

相關問題