Workspace Build Fails with "process cannot access the file" Exception

[terryaney]

Type: Bug

Issue Description

I have a workspace file with multiple projects and interdependent references. When I attempt to build/debug the site, about 50% of the time, I get a process cannot access the file exception.

Steps to Reproduce

Create multiple projects. Hopefully all that is needed to reproduce the result is:

Site -References Library A and Library B Library A - References Library B Library B

My attached workspace image is more complex, but I think from the output you can see the dependency graph. But it is this:

Site:

    <ProjectReference Include="..\..\Domain\src\Camelot.Domain.csproj" />
    <ProjectReference Include="..\..\Infrastructure\src\Camelot.Infrastructure.csproj" />
    <ProjectReference Include="..\..\Api\DataLocker\Contracts\src\Camelot.Api.DataLocker.Contracts.csproj" />
    <ProjectReference Include="..\..\Api\Api\src\Camelot.Api.csproj" />

Camelot.Infrastructure:

    <ProjectReference Include="..\..\Domain\src\Camelot.Domain.csproj" />
    <ProjectReference Include="..\..\Api\WebService.Proxy\Contracts\src\Camelot.Api.WebService.Proxy.Contracts.csproj" />
    <ProjectReference Include="..\..\Api\DataLocker\Contracts\src\Camelot.Api.DataLocker.Contracts.csproj" />
    <ProjectReference Include="..\..\Api\RBLe\Contracts\src\Camelot.Api.RBLe.Contracts.csproj" />
    <ProjectReference Include="..\..\Api\Api\src\Camelot.Api.csproj" />

Camelot.Api:

    <ProjectReference Include="..\..\..\Domain\src\Camelot.Domain.csproj" />

Camelot.Domain:

    <ProjectReference Include="..\..\Api\DataLocker\Contracts\src\Camelot.Api.DataLocker.Contracts.csproj" />
    <ProjectReference Include="..\..\RBLe\Abstractions\Camelot.RBLe.Abstractions.csproj" />

Camelot.Api.RBLe.Contracts:

    <ProjectReference Include="..\..\..\..\RBLe\Abstractions\Camelot.RBLe.Abstractions.csproj" />

Camelot.Api.DataLocker.Contracts, Camelot.Api.WebService.Proxy.Contracts, and Camelot.RBLe.Abstractions have no dependencies.

Expected Behavior

That I can build successfully every time or specify a 'sequential' build process so VS Code/C# knows it has to build things in a certain order.

Actual Behavior

50% of the time, the build fails and I have to just keep attempting it until it succeeds. For example, the following image shows failure:

Then attempting to build immediately after failure succeeds:

Logs

OmniSharp log

Post the output from Output-->OmniSharp log here

C# log

Post the output from Output-->C# here

Environment information

VSCode version: 1.86.0 C# Extension: 2.15.30 Using OmniSharp: true

Dotnet Information

.NET SDK: Version: 8.0.101 Commit: 6eceda187b Workload version: 8.0.100-manifests.30fce108

Runtime Environment: OS Name: Windows OS Version: 10.0.22631 OS Platform: Windows RID: win-x64 Base Path: C:\Program Files\dotnet\sdk\8.0.101\

.NET workloads installed: Workload version: 8.0.100-manifests.30fce108 There are no installed workloads to display.

Host: Version: 8.0.1 Architecture: x64 Commit: bf5e279d92

.NET SDKs installed: 8.0.101 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.26 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.18 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.26 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.18 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 6.0.26 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 8.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found: x86 [C:\Program Files (x86)\dotnet] registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables: Not set

global.json file: Not found

Learn more: https://aka.ms/dotnet/info

Download .NET: https://aka.ms/dotnet/download

Visual Studio Code Extensions

Extension	Author	Version	Folder Name
command-variable	rioj7	1.61.1	rioj7.command-variable-1.61.1
copilot	GitHub	1.156.0	github.copilot-1.156.0
copilot-chat	GitHub	0.12.0	github.copilot-chat-0.12.0
csharp	ms-dotnettools	2.15.30	ms-dotnettools.csharp-2.15.30-win32-x64
dotnet-test-explorer	formulahendry	0.7.8	formulahendry.dotnet-test-explorer-0.7.8
gitlens	eamodio	14.7.0	eamodio.gitlens-14.7.0
live-server	ms-vscode	0.4.13	ms-vscode.live-server-0.4.13
LiveServer	ritwickdey	5.7.9	ritwickdey.liveserver-5.7.9
postman-for-vscode	Postman	0.18.0	postman.postman-for-vscode-0.18.0
rest-client	humao	0.25.1	humao.rest-client-0.25.1
theme-monokai-pro-vscode	monokai	1.2.2	monokai.theme-monokai-pro-vscode-1.2.2
volar	Vue	1.8.27	vue.volar-1.8.27
vscode-autohotkey2-lsp	thqby	2.3.2	thqby.vscode-autohotkey2-lsp-2.3.2
vscode-coverage-gutters	ryanluker	2.11.1	ryanluker.vscode-coverage-gutters-2.11.1
vscode-dotnet-runtime	ms-dotnettools	2.0.1	ms-dotnettools.vscode-dotnet-runtime-2.0.1
vscode-icons	vscode-icons-team	12.7.0	vscode-icons-team.vscode-icons-12.7.0
vscode-nuget-gallery	patcx	0.0.24	patcx.vscode-nuget-gallery-0.0.24
vscode-speech	ms-vscode	0.4.0	ms-vscode.vscode-speech-0.4.0-win32-x64
vscode-xml	redhat	0.26.1	redhat.vscode-xml-0.26.1-win32-x64
xml	DotJoshJohnson	2.5.1	dotjoshjohnson.xml-2.5.1

Extension version: 2.15.30 VS Code version: Code 1.86.0 (05047486b6df5eb8d44b2ecd70ea3bdf775fd937, 2024-01-31T10:28:19.990Z) OS version: Windows_NT x64 10.0.22631 Modes:

System Info

Item	Value
CPUs	13th Gen Intel(R) Core(TM) i7-13700H (20 x 2918)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	undefined
Memory (System)	63.68GB (34.71GB free)
Process Argv	--crash-reporter-id 57256abe-d14d-4e58-98d2-e981d45b881b
Screen Reader	no
VM	0%

A/B Experiments

vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:30899288
vscaat:30438848
c4g48928:30535728
azure-dev_surveyone:30548225
0bi6i642:30951795
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
pythontbext0:30879054
accentitlementsc:30887149
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
dsvsc019b:30953937
3ef8e399:30949928

[dibarbet]

The extension itself doesn't participate in the dotnet build from the commandline that is throwing the error. It may be possible that the extension process is holding onto that dll for some reason, but we haven't seen this issue before (and I'm not able to reproduce with simple references).

A couple questions

1. Is it possible you have a previous instance of the app still running (that didn't shut down correctly) that is causing the file to be locked?
2. Does this reproduce if you invoke the same command line build with VSCode closed?
3. If you're able to figure out which process is holding onto the file, that would give us more information as to if its an extension issue or something else.
4. A binlog might be illuminating here, you can collect one with the -bl:<some binlog name>. If you don't wish to share it publicly, feel free to email me directly (reference this issue #)

[terryaney]

1. No (99% sure)
2. Will test. I mostly see the problem when I want to launch a debug session of the site, but you just want me to run dotnet build from a CLI right?
3. How would I go about doing that?
4. Again, how would I go about doing that? The argument you provided is just an additional argument to the build and/or watch command?

[dibarbet]

Will test. I mostly see the problem when I want to launch a debug session of the site, but you just want me to run dotnet build from a CLI right?

Yeah - basically run the same dotnet build command manually that is being run in the vscode terminal - the exact command and arguments are shown at the top of the terminal in your first screenshot - run that with VSCode closed. Since in this case its the build command that is erroring.

How would I go about doing that?

Believe this can be done via process explorer - think you can search for the file name and see what process is holding onto it. It may or may not work depending on how long lived the process is.

Again, how would I go about doing that? The argument you provided is just an additional argument to the build and/or watch command?

Yup -bl:<some binlog name> would be passed along as another argument to the build.

[dibarbet]

Closing, this is not actionable without the additional information requested. This is also likely not an issue with the extension directly, unless you can see that the process holding onto the file is the C# vscode language server process and preventing the CLI build from succeeding.

[terryaney]

Very randomly reproducible still. Just had it for the first time in the longest time. I'm not sure of the pattern that caused it. I pulled a bunch of repositories and just hit f5 to debug/build 'site' project and got file in use failure. Went to console to try and build and it worked fine. Went back to VS Code and again it worked. So, I understand the 'closing' but just frustrating that this happens every once in a while now, but much less than it used to at least.