roslyn: VBCSCompiler.exe does not end when building .Net Core 3.1 app from Visual Studio 16.4.5

Version Used: We’ve just updated to Visual Studio 16.4.5 a couple of days ago, but this issue has been hitting us for quite some time (sure since 16.4.3 and maybe even before that). Windows 10 1909 (Build 18363.628). VBCSCompiler.exe 3.400.119.61401

Steps to Reproduce: We have a solution with 19 projects (most of them libraries). We are building a client/server solution so we have a Web App (running .Net Core 3.1, exposing a RESTful API) and a Client, which is a WPF app. We are using the MVVM pattern, where the View is the Client WPF project, and the ViewModel and Model are a couple of libraries (DLLs)

  1. We open VS2019 with this solution, and modify something so that the solution needs to be re-compiled.

  2. We run the solution in debug mode for the first time (it is set up with several start projects: both the IIS Express server and the client app). Visual Studio 2019 compiles it fine this time, but it leaves VBCSCompiler.exe running in the background (zombie?). The debug sesion runs fine. We exit the client app and close the browser (which was opened automatically by VS because of the web app is also launched).

  3. We make further changes in the code and try to compile/debug again.

  4. This second time, the compilation fails with errors MSB3027 and MSB3021:

MSB3027	Could not copy "G:\<my-solution>\Library.ViewModel\bin\Debug\netcoreapp3.1\Library.ViewModel.dll" in "bin\Debug\netcoreapp3.1\Library.ViewModel.dll". Exceeded retry count of 10. Failed. The file is locked by: "Microsoft Visual Studio 2019 (65232)"
MSB3021	Could not copy "G:\<my-solution>\Library.ViewModel\bin\Debug\netcoreapp3.1\Library.ViewModel.dll" in "bin\Debug\netcoreapp3.1\Library.ViewModel.dll". The process cannot access the file 'bin\Debug\netcoreapp3.1\Library.ViewModel.dll' because it is being used by another process.
  1. We guess that the proceess VBCSCompiler.exe which is left running from the 1st compilation is the culprit, but as this lock happens most of the times (not always), there might be something else involved that we do not yet know.

  2. a. When the errors appear, manually killing VBCSCompiler.exe does not help (VS still cannot compile, with same errors). We need to exit Visual Studio completely and restart it in order to compile a second time.

    b. If instead of killing VBCSCompiler.exe and exiting VS, we just exit VS, a couple of processes started by VS are left orphaned and running:

  • One is VBCSCompiler.exe, started with the following command line: “C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\VBCSCompiler.exe” “-pipename:cg5s3tyW_oNuSv9ytFEzucuhDSrlb7x2CDdEq6ZbIrc” This is confirmed with Process Explorer, which reports Parent: <Non-existing Process> (instead of MSBuild.exe, which is shown when VS is still running).

  • The other one is dotnet.exe, also initiated by VS with: “dotnet” “C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk.Razor\tools\netcoreapp3.0\rzc.dll” server -p MYUSERNAME.4htt1K2+mTbFo21UFxvtMknhg Process Explorer also report Parent: <Non-existing Process> when left running (instead of MSBuild.exe).

    c. Sometimes, when compilation errors MSB3027 and MSB3021 do not appear, exiting VS still leaves those two processes around. So, there must be something wrong around anyway despite the fact that it does not show up with errors when compiling.

We are running the Spanish-localised version of Visual Studio 2019 (and a Windows 10 in Spanish) but I do not think that has anything to do with the described problem.

Expected Behavior: Visual Studio should compile not only the first time, but any subsequent times without the need to close it and start it again. As you can imagine, developing this way has turned into a nightmare.

Actual Behavior: We believe this is something similar to #37456 (or another regression).

Since this is a solution quite large, making a simpler repro would be desirable, but we do not know where to start trimming the branches. Any help would be appreciated. We could also provide a dump or mini dump of VBCSCompiler.exe if required.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 28 (12 by maintainers)

Most upvoted comments

That pinpointed the root problem! Thanks:)

@rickbrew thanks! Routed to the area I think is likely the cause here.

More feedback in this issue. We’ve narrowed it down to this feature: Enable UI Debugging Tools for XAML which is under VS Options -> Debugging -> General.

Switching off this option (and restarting VS for the change to take effect) and the issue goes away. We’ve been working for two days so far without this problem.

However, when we enable this option (and if during the debugging session we change focus to VS so that Live Visual Tree is shown along with the XAML source file for the current screen in the app), then VS opens our library DLLs and leaves them opened after the debugging has finished, thus preventing further compilations afterwards (that need to replace those very same DLLs).

We are working on a simpler proof-of-concept sample (instead of our original huge solution), but so far we’ve not been able to reproduce the problem with simpler solutions.

It’s ok if you close the issue here. I will try to open a VS feedback issue later, if we finally make a repro in a simpler VS solution.

Thanks.