Freigeben über

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

  • Artikel

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.

Comments

  • Anonymous
    June 11, 2010
    Thank you very much! This resolution worked for me. Although I hope Microsoft finds out some solution to avoid such manual intervention.

  • Anonymous
    June 20, 2010
    So Cisco Security Agent can cause this problem, amazing how much time is wasted due to these tools when these tools are supposed to be saving time and increasing productivity and securing environment Thanks a lot in getting to the root cause. Pankaj

  • Anonymous
    July 29, 2010
    Thanks a lot Steve!  So far the best explanation and best solution given to the XP users.

  • Anonymous
    August 09, 2010
    Thank you Steve.  A great explanation and solution.

  • Anonymous
    September 17, 2010
    The comment has been removed

  • Anonymous
    March 23, 2011
    Super!!! Appreciate compiling all possibilities...

  • Anonymous
    July 02, 2012
    Thanks, there was some redundant folders that when deleted solved the issue.