MSB3021, MSB3026 and MSB3027 during build using Refresh - Windows 10 version 2004 build 19041

[MikeJohnsonDev]

Hi,

Ever since I've updated to Windows 10 version 2004 build 19041, I receive the following warnings and errors every build:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4643,5): warning MSB3026: Could not copy "D:\Current\TestApplication\TestService\obj\x64\Debug\netcoreapp3.1\win7-x64\TestService.exe" to "bin\x64\Debug\netcoreapp3.1\win7-x64\TestService.exe". Beginning retry 10 in 1000ms. The process cannot access the file 'bin\x64\Debug\netcoreapp3.1\win7-x64\TestService.exe' because it is being used by another process. The file is locked by: "TestService (2732)"
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4643,5): error MSB3027: Could not copy "D:\Current\TestApplication\TestService\obj\x64\Debug\netcoreapp3.1\win7-x64\TestService.exe" to "bin\x64\Debug\netcoreapp3.1\win7-x64\TestService.exe". Exceeded retry count of 10. Failed. The file is locked by: "TestService (2732)"
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4643,5): error MSB3021: Unable to copy file "D:\Current\TestApplication\TestService\obj\x64\Debug\netcoreapp3.1\win7-x64\TestService.exe" to "bin\x64\Debug\netcoreapp3.1\win7-x64\TestService.exe". The process cannot access the file 'bin\x64\Debug\netcoreapp3.1\win7-x64\TestService.exe' because it is being used by another process.

This makes it very difficult to develop, as you can imagine.

I also tried a fresh install of Windows 10 version 2004 build 19041 to no avail.

Thanks, Mike

[florisrobbemont]

Hi, We're facing the same issues with Windows 10 version 2004.

Is there an update on this?

Thnx

[Mathyn]

I encounter the exact same issue with Windows Version 2004 (OS Build 19041.508).

[florisrobbemont]

Hey guys,

We're still facing this issue, and the only workaround is to stop the cluster -> Build -> start the cluster. This is costing a lot more time than before, so we're hoping this can be fixed somehow?

It seems that Visual Studio used to do something different before the Windows update. Now when we build we keep getting 'file in use' messages.

Is there something we can do to temporarily fix this? Could it be related to certain permissions?

Hope to hear from you

[MikeJohnsonDev]

Hi @florisrobbemont,

The only workaround I've found is to rollback to Windows 10 version 1909.

Hopefully the Service Fabric team will fix this major issue.

Thanks, Mike

[florisrobbemont]

Is there an update on this?

[MikeJohnsonDev]

Hi @florisrobbemont,

Have you tried Windows 10 version 20H2 yet? I don't really want to update just in case, as I'm nearing project completion.

Thanks, Mike

[ek68794998]

I'm on Windows 10 Enterprise 20H2 (19042.804) and am seeing this issue. Have to taskkill the service's executable during every build to allow it to complete.

[florisrobbemont]

Hi @florisrobbemont,

Have you tried Windows 10 version 20H2 yet? I don't really want to update just in case, as I'm nearing project completion.

Thanks, Mike

I've reinstalled everything last week, and used the latest version of Windows 10 (20H2) but still getting the same results. It appears that Service Fabric is actually running the applications from the bin folder where Visual Studio is building to. So it makes sense these files are locked. I don't know why Service Fabric isn't creating shadow copies of these files, but that might be rooted somewhere in the SDK.

So still having issues...

[jspuij]

This is still an issue. Moreover, I have 5 services and two actors so I'm never able to kill all processes in time to complete a build. I'm stuck to redeploying every time which takes 10 mins between builds. Frankly this issue is making me doubt migrating away from service fabric completely. It's unworkable.

[MikeJohnsonDev]

Hi guys,

Thanks for the updates.

Has anyone tried 8.0 yet?

Thanks, Mike

[strat-alex]

I don't want to hijack this thread, but I'm occasionally having the same issues. I don't think it's related to any OS, as I'm already on windows 11, and I remember having the same issues on windows 10.

I use vs2022 now, but I have seen the same behavior in VS2019 as well. What usually happens is:

• do some work
• f5 (run debug)
• exception thrown or breakpoint hit
• stop the debugger from the stop button in VS
• fix stuff
• f5 again -> get the notification that your exe is locked and cannot be replaced.

Sometimes going into task manager and killing the exe helps. But more often than not, the surefire fix is to reset the cluster.

I checked with sysinternal procexp and the exe was held by FabricHost.exe Hope this helps.

[MikeJohnsonDev]

I decided to move to Kubernetes + Tilt, which works great. I can live update almost instantly with just a build. Far faster than Service Fabric.

Seems that Service Fabric is becoming obsolete. Windows 11 support is not good at all. Kubernetes has better support, more recognition, and a bigger community.