Microsoft.Build.Utilities.FileTracker threw an exception error. Happens with different projects

Lately with Visual Studio 2010 Ultimate, C#, in Win7 64bit, I get the error below when I compile any project. The workaround is to add <TrackFileAccess>false</TrackFileAccess> to the project file. If I am not mistaken this would disable incremental builds so I want to stay away from this workaround.

Anyone knows what the permanent reliable fix is? I did reinstall .NET Framework 4 and VS 2010. I don't have beta or prior versions of 4.0 framework folders.

Error   1   The "GenerateR开发者_开发问答esource" 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 

I found the solution for my environment by reflecting Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Build.Utilities.v4.0.dll

My TEMP/TMP environment variable was pointing to a ram drive root folder (T:\) without any further directory nesting! The line s_tempPath = Path.GetDirectoryName(Path.GetTempPath()); in the static ctor of Microsoft.Build.Utilities.FileTracker resulted in null, which caused the exception as mentioned by you.

Now my TEMP/TMP environment variable is pointing to T:\TEMP and everything is working fine.

Old question but I hope it will help someone who googles it. Its not exactly the Nullref in the original question which was caused by the bug tracked by Microsoft but I want to share it.

I had serious problems building C++ projects which I tracked down to be caused by the Temp environment variables (propably containing spaces in the path names).

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()

Changing TEMP and TMP to:

%USERPROFILE%\Appdata\Local\Temp

solved it.

There's chance that this issue is cause by registry cleaning such as CCleaner 3.x version, after I've executed it, the VS2010 start throw this filetracker issue, I'm pretty sure this is not cause by other action.

Solution, I checked the file does exits or not inside C:\Windows\Microsoft.NET\Framework\v4.0.30319, the Filetracker is still there, then I check do I have multiple 4.0.xxx folder exits? Answer was no.

So I confirm this is not VS issue, it's registry corrupt cause by improper cleaning process.

DOWNLOAD FULL VERSION .net 4.0 Framework and install again, choose repair. Restart PC, now your VS should be working back now.

My point here is, since before occur this incident, you also doesn't make any modification to your Common Target file.

This workaround is from the MS forums:

Edit your project file and add this to the first PropertyGroup:

<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>