"because it is being used by another process" error has me dead in the water. RRS feed

  • Question

  • I've been dealing with this error using VS 2017 for a year now. I compile my solution which contains about 100 projects and some of the projects fail for this reason. I simply build again and the projects that failed will build though other projects might fail further down the line. Ultimately, as I keep building (making no changes in between), they will all pass. Since it only happened on my laptop and desktop and not on the build server I just always did multiple builds and tolerated it.

    However, now it has hit the build server and I can no longer get a build completed, so I had to take the precious time to investigate it more. I tried VS2019 to see it if would change anything - nope. Then I started keeping track of which of the approx. 100 projects it would fail on. That led me to notice that when it failed, it was always where a second compilation pass was occurring. Searching the build log for "MarkupCompilePass2:" revealed that all the projects that failed were undergoing a second compile before the failure. Here is a sample of lines (empty lines added for clarity) from the build log where one of the failure occurs (note my bolding):


    Creating directory "obj\x86\Release_Signed\".

    Project "C:\agent\_work\1\s\VS5\VS5.Comms.SignalStrength\VS5.Comms.SignalStrength.vbproj" (65:2) is building "C:\agent\_work\1\s\VS5\VS5.Comms.SignalStrength\VS5.Comms.SignalStrength_pecgedwc_wpftmp.vbproj" (75) on node 1 (_CompileTemporaryAssembly target(s)).


      C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Roslyn\vbc.exe /noconfig /imports: ... blah, blah, blah ...

      Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Roslyn

    Done Building Project "C:\agent\_work\1\s\VS5\VS5.Comms.SignalStrength\VS5.Comms.SignalStrength_pecgedwc_wpftmp.vbproj" (_CompileTemporaryAssembly target(s)).


      MarkupCompilePass2 successfully generated BAML or source code files.


      Deleting file "obj\x86\Release_Signed\VS5.Comms.SignalStrength.dll".

    ##[error]C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(480,10): Error MSB3061: Unable to delete file "obj\x86\Release_Signed\VS5.Comms.SignalStrength.dll". The process cannot access the file 'C:\agent\_work\1\s\VS5\VS5.Comms.SignalStrength\obj\x86\Release_Signed\VS5.Comms.SignalStrength.dll' because it is being used by another process.

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(480,10): error MSB3061: Unable to delete file "obj\x86\Release_Signed\VS5.Comms.SignalStrength.dll". The process cannot access the file 'C:\agent\_work\1\s\VS5\VS5.Comms.SignalStrength\obj\x86\Release_Signed\VS5.Comms.SignalStrength.dll' because it is being used by another process. [C:\agent\_work\1\s\VS5\VS5.Comms.SignalStrength\VS5.Comms.SignalStrength.vbproj]

    Done Building Project "C:\agent\_work\1\s\VS5\VS5.Comms.Signal


    Is there a way around this?

    Thursday, April 4, 2019 5:21 PM

All replies

  • Thanks for responding. I have tried that (cleaning) - to no avail. I've tried that both on my development system and by choosing that setting on the build server. As for going back from 2017 (where the problem did start), I've made too many changes in the code that 2015 C# language does not support. I'll need to find another way.

    Thursday, April 4, 2019 6:48 PM
  • Just looking at the build log shown above I see the following processes taking place:

    • Create directory for output.
    • Notice that the project contains a XAML with at least one type that will require a second pass compilation.
    • Copy project file to temporary file (one whose filename adds a random string followed by _wpttmp).
    • Compile XAML markup of temporary project (first pass).
    • Compile (second pass).
    • Delete resulting file (this is where it makes no sense - was it copied without logging it first?). However, fails to delete the file because something (I'm guessing compiler) still has it locked.

    Thus I agree with your guess that it is a process spawned to handle the XAML. As far as the applet goes, I think I'd have to run it between the compile/delete process and I don't know how I could get access to that granularity of the build to intervene at the right time. I don't know why it is even deleting the file. If I could intervene, I'd just not clean up (delete) the file.

    One thought I've come up with is to remove all types from XAML so that it can compile in one pass - but I hate doing that since it is like converting constants to magic values.

    The project dependencies scheme is interesting. I'm going to investigate that.

    Thanks for your help so far!

    Thursday, April 4, 2019 8:55 PM
  • I'm back to work. I had the last few days (Fri-Mon a.m.) off to work on moving out of my house.

    Trying to parse your most recent missive, I'm a bit fogged. The build server is running MSBuild with VS closed. I've tried setting the number of concurrent builds to 1 but that didn't help, and I wouldn't expect it to since it is after the second pass of the same compiler on the same file that the file cannot be deleted.

    Let me start with something simple; do you have any idea why CleanupTemporaryTargetAssembly wants to delete the DLL right after it builds it?

    Monday, April 8, 2019 8:38 PM
  • Hi friend,

    Welcome to MSDN forum.

    Does that exist a relationship like the input of A project depends on output of B project in your solution? Which may mess up the build process.

    And if you create a new project with similar structure(several projects), the same issue persists? Since I can't reproduce the same issue on my side, if the issue persists, could you please share the sample here by one-drive so that I can check directly.

    Best Regards


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Thursday, April 18, 2019 10:10 AM
  • I have the same error on my side. It happens sometimes but not each time.

    Did you found something to fix the problem ?
    Wednesday, June 5, 2019 1:48 PM
  • I had this problem on a Jenkins agent, with 10 executors. 
    I found that the problem appeared more frequently when all executors where running at the same time.
    Some builds took 3min when they took only 10 seconds when running alone.

    I then set only 5 executors to lessen the server load. The error "Unable to delete file" disappeared since then.

    It think this error probably comes from a race condition somewhere, and have more free CPU/RAM helps to avoid it.
    Anyway, something has to be fixed in MsBuild.

    • Proposed as answer by DuAell Friday, July 5, 2019 6:02 PM
    Friday, July 5, 2019 6:02 PM
  • I'm seeing the same thing in a WPF application under VS2019. Sometimes, I can't delete the TemporaryTargetAssembly, and it fails the build. I can't repro it consistently, but it happens frequently enough. Has something changed in the build targets for WPF in VS2019?

    Tuesday, July 9, 2019 11:20 PM