C#MS Release build fails with file lock error (workaround: retry)

[allister-beamable]

Description

When triggering a Release (publish) build with 2 or more C# microservices, the build process launches them in parallel. Both services attempt to write the shared Unity.Beamable.Customer.Common output at the same time, causing a file lock conflict and failing both builds.

Workaround: Trigger the Release process a second time — by then the common assembly is already present and the conflict does not recur.

Environment

• Beamable Unity SDK: 5.0.1
• Unity Editor: 6000.3.12f1
• macOS: Tahoe 26.3.1 (a)
• Hardware: MacBook Pro 16-inch Nov 2024, Apple M4 Max, 64 GB RAM
• dotnet SDK: 8.0.302

Steps to Reproduce

1. Create a Unity project with 2+ C# microservices (e.g. AllisterLatestMicroservice, SecondaryService) — reported by Allister MacLeod
2. Open the Beamable publish/release window and trigger a Release build
3. Both services build in parallel

Expected Result

Both services build successfully.

Actual Result

Both services fail. The first service to win the race locks Unity.Beamable.Customer.Common.dll and .deps.json; the second service cannot write them.

Errors

error MSB4018: The "GenerateDepsFile" task failed unexpectedly.
System.IO.IOException: The process cannot access the file
  '.../Unity.Beamable.Customer.Common/bin/Release/net8.0/Unity.Beamable.Customer.Common.deps.json'
  because it is being used by another process.

error CS2012: Cannot open
  '.../Unity.Beamable.Customer.Common/obj/Release/net8.0/Unity.Beamable.Customer.Common.dll'
  for writing -- 'The process cannot access the file ... because it is being used by another process.'

Root Cause (suspected)

The parallel build processes each independently try to build Unity.Beamable.Customer.Common.csproj. The shared output should either be built once before the service builds begin, or service builds should be serialized.

[allister-beamable]

Anecdotally: on my MacBook Pro (M4 Apple Silicon) it feels like it occurs about 20%-50% of the time. Frequent enough to be annoying, but infrequent enough that retrying usually helps.

[cdhanna]

The cause of this is actually this snippet from the microservice .target file,

The problem is that the cache invalidation invalidates the csproj, which means during a large multi-stage solution build, a service that was built on the first half becomes invalid, and msbuild thinks it needs to re-build it on the second half-- which creates a potential for infinite timeout, and GREATLY increases the risk for file lock collisions within msbuild.

<Target Name="beam-invalidate-build-cache" AfterTargets="AfterBuild" Condition="'$(BeamProjectType)'=='service' AND '$(BeamPublish)' != 'true' AND '$(BeamPreventBuildCacheInvalidation)'!='true'">
    <Exec Condition="'$(BeamPlatform)'=='osx'"
          EchoOff="true"
          IgnoreExitCode="true"
          EnvironmentVariables="MSBUILDTERMINALLOGGER=off"
          Command="nohup sh -c 'sleep $(BeamBuildCacheInvalidationTimeout) &amp;&amp; touch $(MSBuildProjectFullPath)' &gt;/dev/null 2&gt;&amp;1 &amp;" 
    />
    <Exec Condition="'$(BeamPlatform)'=='win'"
          EchoOff="true"
          IgnoreExitCode="true"
          EnvironmentVariables="MSBUILDTERMINALLOGGER=off"
          Command="powershell -NoProfile -Command &quot;Start-Process powershell -ArgumentList '-NoProfile -Command &quot;Start-Sleep -Seconds $(BeamBuildCacheInvalidationTimeout); (Get-Item ''$(MSBuildProjectFullPath)'').LastWriteTime = Get-Date&quot;' -WindowStyle Hidden&quot;" 
    />
</Target>

The fix should probably be to default this to false instead of true.

This came about during the federations.json file; when you changed that file, and re-built dotnet, it wouldn't always catch the latest builds, because RIDER specifically has its own file cache that won't even trigger msbuild if the files have not been updated. And Rider didn't care about the federations.json file.
We no longer use the fedreations.json file, so we shouldn't use this cache invalidation by default.

The fix should be to add this to the .props file,

<BeamPreventBuildCacheInvalidation>true</BeamPreventBuildCacheInvalidation>