The "GenerateResource" Task Failed Unexpectedly : Unable to load FileTracker.dll

  • Article

When building a project in Visual Studio 2010 that contains a .resx file, you may receive the following build error:

 

The "GenerateResource" task failed unexpectedly.
System.DllNotFoundException: Unable to load DLL 'FileTracker.dll': A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)
at Microsoft.Build.Shared.NativeMethodsShared.InprocTracking.StartTrackingContextWithRoot(String intermediateDirectory, String taskName, String rootMarker)
   at Microsoft.Build.Utilities.FileTracker.StartTrackingContextWithRoot(String intermediateDirectory, String taskName, String rootMarkerResponseFile)
   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 taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)

 

If you had a version of the Visual Studio 2010 Beta or RC installed on the same machine, you could be hitting a problem where the pre-release uninstaller is leaving a C:\Windows\Microsoft.NET\Framework\v4.0 (or v4.0.xxxx) folder behind. After uninstalling pre-releases and installing the RTM version of Visual Studio 2010 or the .NET Framework 4 you should have a framework folder C:\Windows\Microsoft.NET\Framework\v4.0.30319 and no other v4 folder. You can try renaming any v4 folder other than the RTM v4.0.30319 folder to resolve the build break. More information and other workarounds for this cause can be found on the workarounds tab at the connect bug https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=501894.

 

If this does not apply to you - either you've tried this resolution or you never installed a pre-release of VS2010 or .NET 4 you may be running into an issue we've identified with the CSAUSER.DLL being injected into the MSBUILD or DEVENV process and interfering with the loading of FileTracker.dll. This particular issue has been seen only on Windows XP operating systems.

 

CSAUSER.DLL is a component of the Cisco Security Agent. On Windows XP machines, it appears to be injected into all processes with the usage of the AppInit_DLLs registry key. This registry key is no longer used to inject DLL's in Vista and above systems, which is why this should only reproduce on Windows XP.

 

First, verify that CSAUSER.DLL is in your build process. You can use the TASKLIST command in a DOS Console for this:

 

TASKLIST /M /FI "IMAGENAME eq devenv.exe"

 

If CSAUSER is listed in the modules loaded by the devenv process then you can try safe-mode booting of the OS and testing the build again. If it succeeds, then this issue is most likely hitting you. In a safe-mode boot, the DLL's listed in the AppInit_DLL's registry are not injected into processes.

 

The only workaround at this point beyond removing the Cisco Security Manager or CSAUSER.DLL from the AppInit_DLLs key (which will undoubtedly break the Cisco tool) is to turn off file tracking with the TrackFileAccess=false property in VS 2010, or MSBUILD:

 

msbuild /p:TrackFileAccess=false WindowsFormsApplication1.csproj

 

If building from Visual Studio, add the property to your .CSPROJ file (you can do this with MSBUILD too). In the Solution Explorer, right-click your project and select Unload Project. Right-click it again and select Edit WindowsFormsApplication1.csproj.

 

Then add a global PropertyGroup with the TrackFileAccess property set to false:

 

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <TrackFileAccess>false</TrackFileAccess>
  </PropertyGroup>
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>
... snip the rest of the .csproj file...

 

Save the .csproj file, close it then right-click the project again in the Solution Explorer, and select Reload Project to reload your .csproj file in Visual Studio.

 

You should be able to build without the error at this point. This workaround will turn off incremental resource generation and could have an impact on the performance of incremental builds of managed projects with resources.