In 5.8.0 Preview 1, occasionally UAT stops building because of conflict with horde objs and spews LogRpc errors

Development Pipeline & Plugins
, ,
1

We have an early upgrade to 5.8.0 Preview 1 underway. On a clean workspace, the editor compiles just fine. But something will change in the workspace state, and subsequent runs of UAT to build the code will fail with a spew of errors about LogRpc (see below).

Once this happens, you can’t compile until you clean the workspace, or a more direct work-around is to delete "Engine/Source/Programs/Shared/EpicGames.Horde/uatobj/"

We didn’t see this issue when just compiling the editor, but first time we ran the editor and got to compiling shaders it happened. Once it happens it persists until you wipe the workspace or the uatobj folder. It doesn’t seem to happen every time, so exact reproduction is unknown.

Do you have any suggestions for triaging or fixing?

Thank you.

d:\dev\Engine\Source\Programs\Shared\EpicGames.Horde\obj\Development\net10.0\horde\LogRpcGrpc.cs(40,14): error CS0111: Type 'LogRpc' already defines a member called '__Helper_DeserializeMessage' with the same parameter types
d:\dev\Engine\Source\Programs\Shared\EpicGames.Horde\obj\Development\net10.0\horde\LogRpcGrpc.cs(52,84): error CS0102: The type 'LogRpc' already contains a definition for '__Marshaller_Horde_RpcUpdateLogRequest' [d:\dev\Engine\Source\Programs\Shared\EpicGames.Horde\EpicGames.Horde.csproj]
d:\dev\Engine\Source\Programs\Shared\EpicGames.Horde\obj\Development\net10.0\horde\LogRpcGrpc.cs(54,85): error CS0102: The type 'LogRpc' already contains a definition for '__Marshaller_Horde_RpcUpdateLogResponse' [d:\dev\Engine\Source\Programs\Shared\EpicGames.Horde\EpicGames.Horde.csproj]
[... trimmed from 100's of similar entries ...]
2

Steps to Reproduce

  1. Upgrade to 5.8.0 preview 1
  2. Compile editor
  3. (unknown next step, but possibly run the game and compile shaders, but not 100% repro)
  4. Compile editor again - now UAT will spew errors
3

Hi Rob, I suspect this is because you’re missing the `Directory.Build.targets` files in the root directory at the point where you’re running the build that fails. You appear to have the `Directory.Build.props` file, as that’s what controls whether projects are built to `uatobj` and `uatbin` as opposed to `obj` and `bin`, and `Directory.Build.targets` is responsible for removing any undesired files from the build from the output / intermediate directories that are not in use.

To give a bit of context of why these files are here, it’s to solve a problem of output file thrashing when developers iterate on automation projects via an IDE such as Visual Studio. Before these files were introduced, building in Visual Studio would invalidate all assemblies ran via command-line UAT, and building in command-line UAT would invalidate all assemblies built in Visual Studio, causing constant rebuilds which wasted time. These files solve that by splitting the output locations for each method of running. However, if this isn’t useful to your team, then you can remove both the `Directory.Build.props` and `Directory.Build.targets` file and everything should continue to work correctly for you.