11

I am having an issue with my ASP.NET Web-Api solution where my build agent cannot clean its working directories because the library Microsoft.Bcl.Build.Tasks.dll is still in use by some process so it cannot be deleted. The only things I do in my build agent are to build the solution using standard MSBuild.exe, and then I run a few unit tests using MSTest.exe.

I notice that Microsoft.Bcl.Build version 1.0.14 (the version im using) is listed as a dependency by the Microsoft.Net.Http and also by Microsoft.Bcl libraries.

My workflow in the agent is like this:

  • clone a git repo to the agent
  • build the solution using msbuild
  • test the solution using mstest
  • some time later, maybe 10 minutes, I try and clean up the current iteration
  • cleaning of the files fails due to the described error

My question is this:

Does anyone know why is this library in use by some process even after many minutes? Is there a common process on windows that would be using this library in the background? I would use the process manager to find why this file was in use, but these build machines are considered to be production boxes and are nearly impossible to get admin access to.

Thanks in advance for the help!

Community
  • 1
  • 1
tezromania
  • 797
  • 1
  • 5
  • 18

3 Answers3

4

First delete any usages from processes via a program like LockHunter, then restart VS. It worked for me

Julio Nobre
  • 4,196
  • 3
  • 46
  • 49
jambonick
  • 716
  • 1
  • 6
  • 12
  • 1
    Have used Process Explorer's Find option for the same purpose, but LockHunter is far more practical. Thanks for pointing it out. – Julio Nobre Mar 14 '17 at 14:43
3

If your solution contains custom msbuild targets and those same msbuild targets are in use by another csproj in the same solution, you'll run into a conflict at compile time. Effectively, you'd be trying to compile a part of the compilation process mid-compile and you'll run into these types of file lock errors. The workaround is to split your custom msbuild target project(s) out into a separate solution and build them as-needed. I think you'd need to unload & reload the project that depends on the msbuild targets anytime you rebuild them. Once or twice, I needed to restart VS.

If you didn't add any custom msbuild tasks, you can figure out what is causing the problem by looking at the installed NuGet packages. Right click on your solution and click 'Manage NuGet Packages'. Try to remove Microsoft.Bcl.Build from the Installed packages list. It should fail because something depends on it. Make note of what package depends on it. If the first suggestion didn't help, post back a comment with which packages depend on it and I'll see if I can dig up/remember where else I've seen this before.

This question has more details & links about what Microsoft.Bcl.Build is and what it's used for if you're interested: What does the Microsoft.Bcl.Build NuGet package do?

Community
  • 1
  • 1
scottt732
  • 3,877
  • 2
  • 21
  • 23
  • Your answer seems to address the problem if it were to happen at compile time... however my solution has no troubles at compile time. Only some time later. Are you saying the solution could compile correctly but still have some target lock issue later on? – tezromania Dec 09 '14 at 18:14
  • I've personally seen VS keep locks to dll's involved in the build process until the VS process exits (beyond the lifetime of the build as you'd expect) but I wouldn't expect it from a build agent. See if adding this property helps: http://stackoverflow.com/a/22825192/179223 If it works, you can conditionally add the property via commandline argument rather than manipulating the csproj file. – scottt732 Dec 09 '14 at 20:11
3

I just came across the same problem on my gitlab build server which does a git fetch before every build set.

After adding Microsoft.Bcy.Async from nuget to my project, the step after the build failed with warning: failed to remove packages/Microsoft.Bcl.Build.1.0.14/tools/Microsoft.Bcl.Build.Tasks.dll

With LockHunter I identified several msbuild.exe tasks.

With that info I found the solution here on so: https://stackoverflow.com/a/12193759/98491

Long story short: the msbuild processes are kept open to improve performance while building. This can be disabled by setting the environmentvariable MSBUILDDISABLENODEREUSE=1 or passing /nodeReuse:false to your msbuild itself.

That fixed it for me.

Jürgen Steinblock
  • 30,746
  • 24
  • 119
  • 189