Runtime: MSBuild says dlls are being used by another process when invoking build-tests

[jamesqo]

I have just rebased after the announcement in https://github.com/dotnet/corefx/issues/15135 and run clean --all, build, and build-tests. During build-tests this error pops up when MSBuild tries to copy files from bin\runtime to Tools\testdotnetcli\shared\Microsoft.NETCore.App\9.9.9:

C:\Users\james\Code\git\corefx\Tools\ConstructSharedFx.targets(41,5): warning MSB3026: Could not copy "C:\Users\james\C
ode\git\corefx\bin/runtime/netcoreapp-Windows_NT-Debug-x64/\apphost.exe" to "C:\Users\james\Code\git\corefx\Tools/testd
otnetcli\shared\Microsoft.NETCore.App\9.9.9\apphost.exe". Beginning retry 1 in 1000ms. The process cannot access the fi
le 'C:\Users\james\Code\git\corefx\Tools/testdotnetcli\shared\Microsoft.NETCore.App\9.9.9\apphost.exe' because it is be
ing used by another process. [C:\Users\james\Code\git\corefx\src\tests.builds]

This happens for every file in bin\runtime; the full log is here. (I had to quit the process because it was taking too long, so the log does not include every file in the directory.)

I've tried killing VBCSCompiler.exe and restarting my desktop, but it still happens.

[danmosemsft]

This would tell us what is holding it. https://technet.microsoft.com/en-us/sysinternals/handle.aspx

[weshaggard]

cc @karajas

do you have any dotnet.exe process alive?

[jamesqo]

@danmosemsft I did try using Process Monitor to look at the path before, and nothing came up. I could have done something wrong though (I had just downloaded the program).

[jamesqo]

@danmosemsft Nvm, I thought that Handle was a GUI app like Process Monitor, didn't realize it was actually a command-line program. Here's the output of handle corefx\Tools:

C:\Users\james\Downloads\Handle>handle corefx\Tools

Nthandle v4.1 - Handle viewer
Copyright (C) 1997-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

devenv.exe         pid: 8688   type: File          1634: C:\Users\james\Code\git\corefx\Tools\net45\Microsoft.DotNet.Build.Tasks.dll
devenv.exe         pid: 8688   type: File          1664: C:\Users\james\Code\git\corefx\Tools\net45\roslyn\tools\Microsoft.Build.Tasks.CodeAnalysis.dll
devenv.exe         pid: 8688   type: File          1694: C:\Users\james\Code\git\corefx\Tools\net45\NuGet.Frameworks.dll
devenv.exe         pid: 8688   type: File          16D0: C:\Users\james\Code\git\corefx\Tools\net45\Microsoft.DotNet.Build.Tasks.Packaging.dll

I see Visual Studio using some of the MSBuild assemblies, but there's nothing related to all of the other assemblies that are being used.

[mellinoe]

Can you close Visual Studio and see if that helps?

[jamesqo]

@mellinoe Just edited my question at the bottom after you commented. I just closed VS and verified that handle no longer said devenv was using the assemblies, but it still happens.

[weshaggard]

@jamesqo are you still hitting this issue?

[jamesqo]

@weshaggard Nope, not anymore. I can close this.

[XCJAlves]

Hi @jamesqo - what was the solution to your problem? I am having the same type issue, the gulp task could not run successfully because it says:

C:Program Files (x86)MSBuildMicrosoftVisualStudiov14.0WebDeployMicrosoft.Web.Publishing.Deploy.FileSystem.targets(96,5): error : Copying file objDebugPackagePackageTmpbinSitecore.Mvc.dll to C:WebwwwrootMyCompany\WebsitebinSitecore.Mvc.dll failed. The process cannot access the file 'C:WebwwwrootMyCompany\WebsitebinSitecore.Mvc.dll' because it is being used by another process. [C:XCentiumProjectsMyCompanysrcFoundationThemingcodeMyCompany.Foundation.Theming.csproj]

[hrishikeshtt]

I am facing the same issue while running gulp task for publishing projects

[danmosemsft]

@akuryan what are you building? This issue is about building this repo itsrlf. It would be better to open a new issue as this is closed.

[paivaandeerson]

I don't know why but I fixed this issue using argument verbosity normal level -v n

[camerontbelt]

I don't know why but I fixed this issue using argument verbosity normal level -v n

I have no idea if it just happened to work when I tried this or if this actually fixed the issue, but it worked when I added this at the end of my command in powershell and in the Azure Dev Ops task.