2010-07-11 36 views
9

Últimamente con Visual Studio 2010 Ultimate, C#, en Win7 64 bits, obtengo el siguiente error cuando compilo cualquier proyecto. La solución alternativa es agregar <TrackFileAccess>false</TrackFileAccess> al archivo del proyecto. Si no me equivoco, esto inhabilitaría las compilaciones incrementales, por lo que quiero mantenerme alejado de esta solución alternativa.Microsoft.Build.Utilities.FileTracker lanzó un error de excepción. Ocurre con diferentes proyectos

¿Alguien sabe cuál es la solución confiable permanente? Reinstalé .NET Framework 4 y VS 2010. No tengo versiones beta o anteriores de las carpetas de framework 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 

Respuesta

21

he encontrado la solución para mi entorno por que refleja Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Build.Utilities.v4.0.dll

Mi variable de entorno TEMP/TMP apuntaba a una carpeta raíz de la unidad ram (T: \) sin ningún otro anidamiento de directorios. La línea s_tempPath = Path.GetDirectoryName (Path.GetTempPath()); en el controlador estático de Microsoft.Build.Utilities.FileTracker resultó en nulo, lo que provocó la excepción mencionada por usted.

Ahora mi variable de entorno TEMP/TMP apunta a T: \ TEMP y todo está funcionando bien.

+0

Excelente detective! Tuve el mismo problema. Tenía la DLL abierta en Reflector y estaba comenzando a revisar la clase FileTracker también, cuando vi su publicación. – JustinB

+2

Gracias por la solución. Un pequeño detalle: a veces hay MSBuild.exe bloqueado después de esta excepción (incluso después de cerrar devenv.exe). Deberían ser eliminados para solucionar el problema –

+0

Casi 7 años después y esta solución aún funciona con Visual Studio 2013 Community Edition actualización 4 .. Sheesh. ¡Gracias! –

0

Esta solución es del MS forums:

Editar el archivo de proyecto y añadir esto a la primera PropertyGroup:

<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies> 
+1

No sirvió de nada. El problema mencionado en esa publicación parece ser diferente. –

1

Existe la posibilidad de que este problema sea causado por la limpieza del registro como CCleaner versión 3.x, después de que lo haya ejecutado, el VS2010 inicie este problema, estoy seguro de que esto no se debe a otra acción.

Solución, comprobé si el archivo sale o no dentro de C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319, el Filetracker aún está allí, entonces verifico si tengo varias salidas de carpetas 4.0.xxx? La respuesta fue no.

Confirmo que esto no es un problema VS, es causa de corrupción del registro por un proceso de limpieza inadecuado.

DESCARGAR LA VERSIÓN COMPLETA .NET 4.0 Framework e instalar nuevamente, elija reparar. Reinicia tu PC, ahora tu VS debería estar funcionando ahora.

Mi punto aquí es que, dado que antes ocurría este incidente, tampoco hace ninguna modificación a su archivo de objetivo común.

2

Pregunta anterior, pero espero que ayude a alguien que la busque. No es exactamente el Nullref en la pregunta original que fue causado por el error rastreado por Microsoft, pero quiero compartirlo.

Tuve serias dificultades para crear proyectos en C++ que rastreé para que fueran causados ​​por las variables de entorno Temp (que contienen espacios de manera propagable en los nombres de ruta).

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

Cambio TEMP y TMP a:

%USERPROFILE%\Appdata\Local\Temp 

resuelto.

+0

Tenga en cuenta que 'C: \ Users \ David \ Configuración local \ Temp' no es lo mismo que' C: \ Users \ David \ AppData \ Local \ Temp'. Si bien pueden vincularse al mismo lugar a través de unión, uno da el error de menciones BlueM y el otro funciona correctamente (pista: El que BlueM enumera es la respuesta correcta). –

Cuestiones relacionadas