none
The requested operation cannot be performed on a file with a user-mapped section open

    Pregunta

  • Hello,

    I am currently experiencing an intermittent MSBuild error which manifests itself as follows (see MSBuild log output below, company name withheld). This problem has only started occurring within the last month or so. In this particular instance the error occurred on a TFS build server during a non-incremental build, i.e. no intermediate or reference assemblies existed before the build commenced.

    However this problem is not confined to this particular VS solution (and or reference assemblies), rather frustratingly this issue seems to occur almost at random across multiple different and sometimes unrelated solutions. It is also not the case that this problem is confined to this particular build server. All our developers use the same TFSBuild.proj to build our trunk locally. Some developers are reporting this issue regularly where as others have never experienced the problem. At first I was inclined to believe that the problem was a result of having solutions open in VS whilst simultaneously trying to use MSBuild to build the same solutions but this also does not seem to have any effect on the success or failure of the build.

    Any ideas? Thank you in advance for any assistance.

    don

    ~~~~~~~~~~~~~~~~~~~~~~~[Sample MSBuild (TFSBuild) error output]~~~~~~~~~~~~~~~~~~~~~~~~~

    Target "GetTargetPath" in file "c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets" from project "C:\Builds\127\Sources\src\Desktop\Common\CompanyName.Desktop.Common.csproj":
    Building target "GetTargetPath" completely.
    No input files were specified.
    Done building target "GetTargetPath" in project "CompanyName.Desktop.Common.csproj".
    Target "ComputeIntermediateSatelliteAssemblies" skipped. Previously built successfully.
    Target "_CopyFilesMarkedCopyLocal" in file "c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets" from project "C:\Builds\127\Sources\src\Desktop\Common\CompanyName.Desktop.Common.csproj":
    Task "Copy"
      Copying file from "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Shared.v7.2.dll" to "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Shared.v7.2.dll".
      Command:
      copy /y "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Shared.v7.2.dll" "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Shared.v7.2.dll"
    c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2703,9): error MSB3021: Unable to copy file "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Shared.v7.2.dll" to "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Shared.v7.2.dll". The requested operation cannot be performed on a file with a user-mapped section open.
    c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2703,9): error MSB3021:
      Did not copy from file "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Win.Misc.v7.2.dll" to file "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Win.Misc.v7.2.dll" because the "SkipUnchangedFiles" parameter was set to "true" in the project and the files' sizes and timestamps match.
      Copying file from "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Win.UltraWinDataSource.v7.2.dll" to "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Win.UltraWinDataSource.v7.2.dll".
      Command:
      copy /y "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Win.UltraWinDataSource.v7.2.dll" "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Win.UltraWinDataSource.v7.2.dll"
    c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2703,9): error MSB3021: Unable to copy file "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Win.UltraWinDataSource.v7.2.dll" to "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Win.UltraWinDataSource.v7.2.dll". The requested operation cannot be performed on a file with a user-mapped section open.
    c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2703,9): error MSB3021:
      Did not copy from file "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Win.UltraWinEditors.v7.2.dll" to file "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Win.UltraWinEditors.v7.2.dll" because the "SkipUnchangedFiles" parameter was set to "true" in the project and the files' sizes and timestamps match.
      Copying file from "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Win.UltraWinGrid.v7.2.dll" to "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Win.UltraWinGrid.v7.2.dll".
      Command:
      copy /y "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Win.UltraWinGrid.v7.2.dll" "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Win.UltraWinGrid.v7.2.dll"
    c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2703,9): error MSB3021: Unable to copy file "..\..\ThirdParty\Infragistics\Windows Forms\7.2\Infragistics2.Win.UltraWinGrid.v7.2.dll" to "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Win.UltraWinGrid.v7.2.dll". The requested operation cannot be performed on a file with a user-mapped section open.
    miércoles, 23 de septiembre de 2009 8:15

Respuestas

  • Thank you Hongye for the suggestion. It was something I had considered myself however the lock appears to be so transient that by the time you attempt to determine the file handles which are acquired at the time the error occurs the build has moved on and no process has a handle to the file. I think however that I may have some new insight into the problem.

    I dug a little deeper into the csproj files associated with the solution and noticed that there were features of the projects which could be causing this behaviour (1) the were a mixture of two different Infragistics hint paths in the assembly reference ItemGroup (I *know* two copies of the same third party library in the same branch!!) and (2) the projects were building to a common higher-level output bin directory. As a consequence at build time MSBuild was determining (quite correctly) that the Infragistics files being referred by one project were different (in terms of timestamp) to the copies of the files in the high-level output bin. This is why the copy to "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Shared.v7.2.dll" (see original post) was taking place.

    Fortunately I was able to tweak the projects (by using different reference paths for Infragistics in the Common.csproj and a dependent csproj) and get the error to occur in a repeatable fashion. In short fixing the Infragistics hint paths solved the issue - by preventing dependent projects from wanting to overwrite copies of their third-party binary references which already existed in the high-level output bin. This still seems a bit of an unsatisfactory solution (you'd think I'd be happy the build was running) given that a number of developers never experienced the issue even with the bad hint paths. I'm guessing that there must be a some kind of timing and or environmental factors which will increase the likely hood of seeing this issue. Moral of the story, pay close attention to where your projects are picking their binary references up from and what ever you do don't reference the same file from two different locations or you'll upset the guy running the builds ;)
    • Marcado como respuesta vu1garis jueves, 24 de septiembre de 2009 13:29
    jueves, 24 de septiembre de 2009 13:28

Todas las respuestas

  • The error message: "The requested operation cannot be performed on a file with a user-mapped section open." indicates that the file is in use by other process. 

    Please download and run process explorer at: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
    In menu Find / Find Handle or DLL / type the file name, for instance: "Infragistics2.Shared.v7.2.dll".
    Check if there is any Handle which is opened by other processes.
    Close those process and restart the build again.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    jueves, 24 de septiembre de 2009 1:45
  • Thank you Hongye for the suggestion. It was something I had considered myself however the lock appears to be so transient that by the time you attempt to determine the file handles which are acquired at the time the error occurs the build has moved on and no process has a handle to the file. I think however that I may have some new insight into the problem.

    I dug a little deeper into the csproj files associated with the solution and noticed that there were features of the projects which could be causing this behaviour (1) the were a mixture of two different Infragistics hint paths in the assembly reference ItemGroup (I *know* two copies of the same third party library in the same branch!!) and (2) the projects were building to a common higher-level output bin directory. As a consequence at build time MSBuild was determining (quite correctly) that the Infragistics files being referred by one project were different (in terms of timestamp) to the copies of the files in the high-level output bin. This is why the copy to "C:\Builds\127\Sources\Bin\Mixed Platforms\Release\Infragistics2.Shared.v7.2.dll" (see original post) was taking place.

    Fortunately I was able to tweak the projects (by using different reference paths for Infragistics in the Common.csproj and a dependent csproj) and get the error to occur in a repeatable fashion. In short fixing the Infragistics hint paths solved the issue - by preventing dependent projects from wanting to overwrite copies of their third-party binary references which already existed in the high-level output bin. This still seems a bit of an unsatisfactory solution (you'd think I'd be happy the build was running) given that a number of developers never experienced the issue even with the bad hint paths. I'm guessing that there must be a some kind of timing and or environmental factors which will increase the likely hood of seeing this issue. Moral of the story, pay close attention to where your projects are picking their binary references up from and what ever you do don't reference the same file from two different locations or you'll upset the guy running the builds ;)
    • Marcado como respuesta vu1garis jueves, 24 de septiembre de 2009 13:29
    jueves, 24 de septiembre de 2009 13:28
  • I had a folder open in the VS tabbed windows in the project and on closing it it solved the proble.

    Hope this helps anyone out there.

    lunes, 11 de junio de 2012 18:03
  • I started getting this problem out of the blue when trying to save ordinary html files after editing with EW4. I had recently installed Copernic desktop search (because Windows Explorer file search doesn't work properly - can't find "center" as in "align="center"" in a dumb html file for example). As soon as I had removed Copernic, I could save my EW2 html files again. This happened on Windows 7 Home Premium 64-bit. 

    Back to square one finding another desktop file search program that works.

    jueves, 22 de noviembre de 2012 23:43
  • I had this problem due to antivirus running over the solution folder.
    miércoles, 19 de junio de 2013 5:52