Packaging fails when trying to create StagedBuildsDirectory with a trailing drive letter

anonymous_user_6905364c · May 17, 2016, 4:07pm

Hi guys,

It seems the packaging process is trying to create an invalid directory towards the end the packaging process.

MainFrameActions: Packaging (Windows (64-bit)): Project.CreatePak: UnrealPak Done *******
MainFrameActions: Packaging (Windows (64-bit)): Project.CopyManifestFilesToStageDir: Copying NonUFSFiles to staging directory: E:\P4\ZoneUE4\Saved\StagedBuilds\WindowsNoEditor
MainFrameActions: Packaging (Windows (64-bit)): Program.Main: ERROR: AutomationTool terminated with exception: AutomationTool.AutomationException: Failed to create directory E:\P4\ZoneUE4\Saved\StagedBuilds\WindowsNoEditor\E: for copy
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.CommandUtils.CopyFileIncremental(String Source,
MainFrameActions: Packaging (Windows (64-bit)): String Dest, Boolean bAllowDifferingTimestamps, Boolean bFilterSpecialLinesFromIniFiles) in E:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\AutomationUtils\CommandUtils.cs:line 1373
MainFrameActions: Packaging (Windows (64-bit)): at Project.CopyManifestFilesToStageDir(Dictionary2 Mapping, String StageDir, String ManifestName, List1 CRCFiles) in e:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\Scripts\CopyBuildToStagingDirectory.Automation.cs:line 658
MainFrameActions: Packaging (Windows (64-bit)): at Project.CopyUsingStagingManifest(ProjectParams Params, DeploymentContext SC) in e:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\Scripts\CopyBuildToStagingDirectory.Automation.cs:line 723
MainFrameActions: Packaging (Windows (64-bit)): at Project.ApplyStagingManifest(ProjectParams Params, DeploymentContext SC) in e:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\Scripts\CopyBuildToStagingDirectory.Automation.cs:line 1246
MainFrameActions: Packaging (Windows (64-bit)): at Project.CopyBuildToStagingDirectory(ProjectParams Params) in e:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\Scripts\CopyBuildToStagingDirectory.Automation.cs:line 1767
MainFrameActions: Packaging (Windows (64-bit)): at BuildCookRun.DoBuildCookRun(ProjectParams Params) in e:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\Scripts\BuildCookRun.Automation.cs:line 217
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.BuildCommand.Execute() in E:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\AutomationUtils\BuildCommand.cs:line 28
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.Automation.Execute(List1 CommandsToExecute, CaselessDictionary1 Commands) in E:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\AutomationUtils\Automation.cs:line 539
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.Automation.Process(String[] CommandLine) in E:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\AutomationUtils\Automation.cs:line 510
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.Program.MainProc(Object ) in E:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\Program.cs:line 131
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.InternalUtils.RunSingleInstance(Func`2 Main, Object ) in E:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\AutomationUtils\Utils.cs:line 704
MainFrameActions: Packaging (Windows (64-bit)): at AutomationTool.Program.Main() in E:\UE4.1.1-Release\Engine\Source\Programs\AutomationTool\Program.cs:line 54
MainFrameActions: Packaging (Windows (64-bit)): Program.Main: AutomationTool exiting with ExitCode=1 (Error_Unknown)
MainFrameActions: Packaging (Windows (64-bit)): Domain_ProcessExit
MainFrameActions: Packaging (Windows (64-bit)): AutomationToolLauncher exiting with ExitCode=1
MainFrameActions: Packaging (Windows (64-bit)): copying UAT log files…
MainFrameActions: Packaging (Windows (64-bit)): BUILD FAILED
PackagingResults:Error: Error Unknown Error

Notice the invalid directory “Failed to create directory E:\P4\ZoneUE4\Saved\StagedBuilds\WindowsNoEditor\E:” which seems to have a trailing E: which of course is not allowed by windows. Packaging has created the “E:\P4\ZoneUE4\Saved\StagedBuilds\WindowsNoEditor” folder fine and it contains the .exe but not much else.

I have cleared the saved/intermediate folders before packaging. What would cause this behavior?

Cheers,

anonymous_user_e729f54e · May 18, 2016, 2:56pm

Hello SkurkSE,

I have a few questions for you that will help narrow down what issue it is that you are experiencing.

Quick questions:

Can you reproduce this issue in a clean project?
If so, could you provide a detailed list of steps to reproduce this issue on our end?
Could you provide screen shots of any packaging settings you may be using that could be involved with this issue?

anonymous_user_6905364c · May 23, 2016, 9:26am

Sorry, I missed this answer :).
I will try to repro with a clean project later today. Right now my plan of attack is to rebuild my sourcebuild of the engine and the project with a different path and then download a vanilla UE4 through the launcher and attempt to package with that one.

anonymous_user_6905364c · May 24, 2016, 7:19am

After some investigation yesterday it turned out to be a third party plugin causing the issue. They will be looking into the problem and this thread can be closed for now.

anonymous_user_9051f221 · May 25, 2016, 8:09am

Hello!
Author of the third party plugin here. I’m able to reproduce the problem 100% in 4.11.1, but not in 4.10.4.
I have also been unable to see any reason that the plugin would cause a drive letter to be appended. And I have no clue on how to track it down!
Please pm me and I can provide a copy of the plugin.
Image of the settings that are set for packaging. Note that the same settings do not seem to cause any problems when the plugin is not in use.

kamrann · May 26, 2016, 4:05am

Update (plugin programmer):

The issue is in fact caused by the following line in the plugin module build script:

RuntimeDependencies.Add(new RuntimeDependency(EliasDllFilepath, DllStagePath));

where DllStagePath is a relative path within the staging directory, at which location we wish to deploy the 3rd party dll used by the plugin. It worked fine in 4.10, but as of 4.11 this path gets mangled at some point during the build/receipt process, and generates the error when it is then later used.

Using the RuntimeDependency constructor with just a single argument gets rid of the error, but means the dll ends up at the same relative path it exists in the plugin directory, and the deployed executable is unable to locate the dll.

Until the StagePath issue can be fixed, any suggestions for how to let the generated executable know where the dll is? Engine 3rd party dlls are found without issue, how is this achieved?

kamrann · May 26, 2016, 4:07am

Reopening question, please see above comments.

Joe_Conley · June 2, 2016, 6:33am

Hi and ,

Thanks for investigating this problem for us.

I’ve added this issue to our bug database as UE-31537 - “Adding a RuntimeDependency causes errors in packaging on Windows and PS4”.

I haven’t confirmed whether or not the issue is present in the latest release that came out just today (4.12), or if it’s present in our latest development branches. If you happen to have a sample project that runs in standard UE4, that would probably speed up our investigation of this issue. Hopefully we can have more information for you soon.

Thanks again for the report!

kamrann · June 2, 2016, 8:39am

Hi Joe, here you go.
See the code and comments in RuntimeDependencyRepro.Build.cs.

Joe_Conley · June 10, 2016, 4:16am

Thanks !

Just got an update on this from our build team engineer, and it looks like this code has changed in 4.12 so this problem shouldn’t happen in the future. His comment was:

“This code doesn’t exist in 4.12. DLLs now have to be kept in the same relative path as they would appear in a staged build, so there is no second parameter to the RuntimeDependency constructor.”

Hope that fixes things!

Thanks.

kamrann · June 23, 2016, 11:02am

Thanks for the update, but removing the functionality seems a strange way of fixing a bug.

Can I put in a request that this option be reimplemented?

In the case of dlls within plugins, this means that the only workaround is to force the dll to be delay-loaded and then make sure you explicitly load it before the OS tries and fails.

This doesn’t only apply to dlls though - it just seems an obvious thing to provide some control over where dependencies are deployed.

BjornTR · February 16, 2017, 12:18pm

Getting rid of a very useful feature that allows dll’s to be placed in logical places on windows is not a good way of fixing an issue.
What is the workaround to this? If it’s delay loading, I’m having serious trouble with this on a different platform!
Best regards,