Cannot rebuild projects due to exe file being locked

SteveSandersonMS commented 3 months ago

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug

I'm running https://github.com/dotnet/eShopSupport from VS, launching using Ctrl+F5. I understand that when subsequently building a referenced project (e.g., the Backend project in that solution), VS is supposed to shut down and restart that one project while leaving AppHost running (citation).

However, the vast majority of the time, this does not work for me, and building a referenced project fails with errors like:

1>C:\Program Files\Microsoft Visual Studio\2022\IntPreview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(5321,5): warning MSB3026: Could not copy "D:\git\dotnet\eShopSupport\src\Backend\obj\Debug\net8.0\apphost.exe" to "bin\Debug\net8.0\Backend.exe". Beginning retry 1 in 1000ms. The process cannot access the file 'bin\Debug\net8.0\Backend.exe' because it is being used by another process. The file is locked by: "Backend (2592)"
1>C:\Program Files\Microsoft Visual Studio\2022\IntPreview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(5321,5): warning MSB3026: Could not copy "D:\git\dotnet\eShopSupport\src\Backend\obj\Debug\net8.0\apphost.exe" to "bin\Debug\net8.0\Backend.exe". Beginning retry 2 in 1000ms. The process cannot access the file 'bin\Debug\net8.0\Backend.exe' because it is being used by another process. The file is locked by: "Backend (2592)"
1>C:\Program Files\Microsoft Visual Studio\2022\IntPreview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(5321,5): warning MSB3026: Could not copy "D:\git\dotnet\eShopSupport\src\Backend\obj\Debug\net8.0\apphost.exe" to "bin\Debug\net8.0\Backend.exe". Beginning retry 3 in 1000ms. The process cannot access the file 'bin\Debug\net8.0\Backend.exe' because it is being used by another process. The file is locked by: "Backend (2592)"
1>C:\Program Files\Microsoft Visual Studio\2022\IntPreview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(5321,5): warning MSB3026: Could not copy "D:\git\dotnet\eShopSupport\src\Backend\obj\Debug\net8.0\apphost.exe" to "bin\Debug\net8.0\Backend.exe". Beginning retry 4 in 1000ms. The process cannot access the file 'bin\Debug\net8.0\Backend.exe' because it is being used by another process. The file is locked by: "Backend (2592)"
etc.

I've tried VS versions:

Version 17.11.0 Preview 4.0
Version 17.12.0 Preview 1.0 [35117.301.main]

and have disabled every VS extension I can, and disabled hot reload, but the same issue remains.

This is the most impactful issue on productivity when working on this project, as there's no choice but to manually kill and restart AppHost for literally every code change, which in turn means restarting some large Docker containers including Ollama.

I don't think it's specifically a problem in the app code, because it sometimes works. If I restart VS often enough and keep deleting the .vs directory, then occasionally it can rebuild the referenced projects without the file being locked. But this is a short-lived victory as the locking problem soon comes back and is present the vast majority of the time.

Expected Behavior

VS should be able to rebuild referenced projects without failing due to the .exe or .dll files being locked.

Steps To Reproduce

Clone and run https://github.com/dotnet/eShopSupport (via Ctrl+F5 in VS)
Visit StaffWebUI and observe it working
Make any edit (e.g., whitespace) in src/Backend/Program.cs and try to build that one project
Expected: builds that one project while leaving AppHost running
Actual: fails with the "file locked" error mentioned above

Exceptions (if any)

No response

.NET Version info

.NET SDK: Version: 8.0.400-preview.0.24324.5 Commit: 736a2616db Workload version: 8.0.400-manifests.7ccdde63 MSBuild version: 17.11.0+1192b22fd

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.400-preview.0.24324.5\

.NET workloads installed: Configured to use loose manifests when installing new manifests. [aspire] Installation Source: SDK 8.0.400-preview.0, VS 17.11.35111.106, VS 17.12.35117.301 Manifest Version: 8.0.2/8.0.100 Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.2\WorkloadManifest.json Install Type: Msi

Host: Version: 8.0.7 Architecture: x64 Commit: 2aade6beb0

.NET SDKs installed: 7.0.120 [C:\Program Files\dotnet\sdk] 8.0.107 [C:\Program Files\dotnet\sdk] 8.0.400-preview.0.24324.5 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 6.0.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.19 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.19 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.30 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.19 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Anything else?

Aspire packages are all 8.0.2

davidfowl commented 1 month ago

@vijayrkn I put this in 9.0. We should look at it.

BillHiebert commented 3 weeks ago

@davidfowl , @SteveSandersonMS so far I have not been able to reproduce this. When looking more closely at the code I discovered that VS is not handling replicas properly. It was only stopping and restarting the first one. I have a PR out with a fix for that, but this project does not use replicas so something else must be going on. From the VS side the code is very straight forward and it is difficult to see a case where it would not stop the process - unless the call to stop the process failed.

dotnet / aspire