Since CL 53811643 (Main) / CL 53811643 (5.8), UE5 engine seems to have added Directory.Build.props and Directory.Build.targets files, in order to move the project output folders from obj/bin to uatobj/uatbin.
Somewhat related: In 5.8.0 Preview 1, occasionally UAT stops building because of conflict with horde objs and spews LogRpc errors
Now, I noticed that FAB-listed LyraStarterGame for 5.8 seems to contain binaries under uatobj folder path as well, but the sample does not ship with the above mentioned Directory.Build.* files. If I download and generate this project fresh outside my engine tree, and then open Lyra.uproject with my editor build, Turnkey shows error “…\LyraStarterGame\Build\Scripts\obj\Development\net10.0\Lyra.Automation.AssemblyInfo.cs(13,12): error CS0579: Duplicate ‘System.Reflection.AssemblyCompanyAttribute’ attribute […\LyraStarterGame\Build\Scripts\Lyra.Automation.csproj]”. This seems to be due to local iteration generating files to obj folder since that path does not contain Directory.Build.* in its ancestry, and generated definition there conflicts with FAB-shipped files in uatobj folder. Removing included uatobj folder, or copying over Directory.Build.* files seem to be possible workarounds.
2 Questions:
1) Which is the recommended workaround approach here? If latter is more appropriate, shouldn’t samples contain their own Directory.Build.* files?
2) Does (1) apply to other UE5.8 projects as well? Namely, is there something in UAT/UBT and related pipeline that now makes assumption that uatobj/uatbin is used instead of the default obj/bin folder names?
Hi Shinsuke,
Either of the workarounds you identified (removing the `uatobj` folder or copying over `Directory.Build.*` files) are fine. The reason that the `Directory.Build.*`. As noted in the post you linked, the intention behind these `Directory.Build.*` files is to reduce iteration time when working on automation projects within an IDE - if you’re using the Lyra project as a base to build your own automations, then I’d suggest you add those files in. If you’re not, then I’d instead suggest deleting the `uatobj` directory.
The behaviour in the `Directory.Build.*` files is keyed off the MSBuild property `EpicGamesMsBuild`, which is set when assemblies are being compiled by an Epic tool (UBT or UAT). As such, this does extend to all assemblies that are compiled by UBT (`*.ubtplugin.csproj`) and UAT (automation projects and their dependencies), but as long as there are no mismatches (i.e. the situation you described, a `uatobj` directory without `Directory.Build.*` files), everything should work correctly.
My apologies that you encountered this problem, I’m making enquiries internally to learn about how the Lyra sample project is published to see if we can get a rectified version without this issue.
We’ve fixed the problem in source, and I’m hopeful that new sample projects will get published for the release of UE 5.8.2. Thanks very much for your patience.
Thank you for the details. Your response reassured that our approach is indeed correct.
FWIW, out of the Epic official samples I have tried (Stack-O-Bot, Lyra and CitySample), CitySample for 5.8 also ships with prebuilt uatobj directory, so unless either (1) or (2) is applied will likely result in similar build failure as well.
Great! Thank you for taking time to address the issue. Makes future use much easier.