The short version is, the directory "Engine/Source/Programs/AutomationTool/Mutable/RunMutableCommandlet/obj/" is marked as read-only in 5.5 and I don’t think it should be.
Longer story, our automated build pipeline broke after we updated to 5.5. Manually building with VisualStudio GUI was fine, but our automated scripts were busted. It runs this command… "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.com" MyProject.sln /build "Development Editor"
Then I was errors like… Error occurred while restoring NuGet packages: Access to the path 'C:\GameEngines\UE_5.5\Engine\Source\Programs\AutomationTool\Mutable\RunMutableCommandlet\obj\RunMutableCommandlet.Automation.csproj.nuget.g.props' is denied.
and
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(5807,5): error MSB3491: Could not write lines to file "obj\Development\RunMutableCommandlet.Automation.csproj.FileListAbsolute.txt". Access to the path 'C:\GameEngines\UE_5.5\Engine\Source\Programs\AutomationTool\Mutable\RunMutableCommandlet\obj\Development\RunMutableCommandlet.Automation.csproj.FileListAbsolute.txt' is denied.
I checked and that whole obj directory is marked as read-only for this program, and it does NOT appear read-only for other ones. Clearing the read-only flag from this directory allows my autobuild scripts to work again.
Sharing in case anyone else hits the issue, and so that if this was indeed done in error then maybe it can be fixed in the next patch.
I am experiencing the same issue. As you mentioned, I removed the read-only flag from the obj folder, but the folder automatically reverts to read-only again. So, I couldn’t apply this as a solution.
Can confirm, having the same issue with a brand new 5.5 install.
This worked fine for a few builds, then it started failing with access restrictions.
Checked and these folders were all marked as read only.
I got same error when doing Build Solution in VS (F6 shortcut). But when specifically build the project under the solution then there is no error.
Solved it by removing “Build” checkbox in Solution properties → Configuration properties → Configuration → “RunMutableCommandlet.Automation”. I also do not build the engine “UE5” so those two are unchecked and no more error. Not sure if there will be any consequences down the line or why those additional components are checked to build by default at all if not building engine from source anyways.
Had this - I don’t think it’s actually a bug though: After I updated Rider to 2024.3 I no longer got this message when I tried to compile. Based off another message I got when opening a project I think the prerequisites got changed for 5.5
I’d recommend anyone getting hit with this update their IDE to the latest version like I did.
After removing the read-only flag from the obj folder located in UE_5.5\Engine\Source\Programs\AutomationTool\Mutable\RunMutableCommandlet, running the command dotnet add package System.Data.DataSetExtensions --version 4.5.0 resolved the issue for me.
I also have the same issue. Run dotnet add package System.Data.DataSetExtensions --version 4.5.0 only introduced other types of issues with nuget packages
If epic has a definit solution that woule be the best.
I’ve had the same issue as @Fosere, it works for a few builds and then gives the error.
And just as @sariogluCagatay says, the folder automatically reverts to ‘read only’… regrettably, the terminal solution only worked once.
I’m using the latest update of Visual Studio, and I fixed the Nuget error with @vfXander’s thread
But still getting this MSB3073 Build.bat error
PS. I’m beginning to suspect that, as a C++ beginner, that it’s the projects cloned in the Laucher that are giving this error. As the ‘Renaming projects in C++ isn’t fully supported’ cloning warning goes… maybe this is what is causing my issue with this. At the moment, projects created from scratch aren’t giving me the MSB3073 Build.bat error.
PPS. I’ve found that restarting Visual Studio also sometimes works.
