Could you please elaborate on your step 7? What is the exact process that you follow to start the build after making sure you are building for Development Editor and Win64? All of the methods that I have tried so far have built successfully for me, and I want to make sure I have not overlooked anything.
I select “Build Project” from the drop-down menu in Visual Studio and let it run.
I tried three different methods to build the engine using a drop-down menu in Visual Studio, and they all unfortunately built successfully for me. First I used the context menu from the UE4 project in the Solution Explorer.
This build ended with the result: ========== Build: 4 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Next I used the Build Project option in the Build menu with the UE4 project selected.
This ended with the same result as the first build.
Then I used the Build Only Project option in the Build menu with the UE4 project selected.
This one ended with the result ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========, but the Editor won’t open successfully due to missing dependencies.
In all three options for me, the OneSkyLocalizationService seemed to build fine.
Is there a different drop-down menu or option that you are using?
I also just re-read through the repro steps that you provided initially and realized that you are rebuilding your project in the later steps instead of just building it. Rebuilding the project in Visual Studio will also rebuild the Engine, which may explain why you see these same errors whenever you rebuild your project.
My apologies, I was away from Visual Studio when I replied last.
I’ve been using Build->Build Solution and Build->Rebuild Solution; both in my Game project and in the Engine project.
Yes, I suspect the behavior in the game project is because performing Rebuild Solution builds the engine as well as the game. I can continue developing my game project, perform “Build->Build Solution” (in my game project), launch the editor, and test my game in PIE. I haven’t attempted any packaged builds.
I include the Game project info only to demonstrate that rebuilding the engine fails consistently both from within the engine project and from my game project.
Within the UE4 Engine project:
- Build->Rebuild Solution always fails. (see OP step 9)
- Build->Build Solution fails on the first build, but works on subsequent builds. (see OP step 7 vs. step 8)
Within the Game project:
- Build->Rebuild Solution always fails (see OP step 15)
- Build->Build Solution works (see OP step 13)
That’s the behavior I was describing by “First Build Project fails and Rebuild Project consistently fails” in my original post; sorry if this was unclear.
Are there dependencies for OneSkyLocalization that may exist on your test machine already; i.e. the clean install of UE4.13 would work even if the installer isn’t downloading those dependencies?
For the sake of clarity:
I’m running the UE4.13.0 Engine project within Visual Studio 2015 Community on Ultimate 64.
Performing “Build->Build Solution” fails the first time I perform it on a new engine install. Subsequent runs of “Build->Build Solution” succeed.
In order to duplicate the fail behavior you’d have to perform a clean install of the game engine each time you try “Build->Build Solution”.
Performing a full “Build->Rebuild Solution” fails consistently.
Duplicating the fail behavior of “Build-Rebuild Solution” should be consistent; at least it is on my end.
I’ve downloaded the 14.13.1 (release) branch from GitHub and have the same behavior.
When I look at the logs it appears that the first Build Solution and Rebuild Solution always fails to build the automation assemblies, but a second (and subsequent) attempt at Build Solution successfully builds the automation assemblies.
First Build Solution / Every Rebuild Solution:
47>CSC : error CS0006: Metadata file '~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\AutomationScripts.Automation.dll' could not be found
46>CSC : error CS0006: Metadata file '~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\AutomationScripts.Automation.dll' could not be found
11> Creating makefile for ShaderCompileWorker (no existing makefile)
11> Performing full C++ include scan (no include cache file)
48>CSC : error CS0006: Metadata file '~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\Android\Android.Automation.dll' could not be found
48>CSC : error CS0006: Metadata file '~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\AutomationScripts.Automation.dll' could not be found
48>CSC : error CS0006: Metadata file '~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\HTML5\HTML5.Automation.dll' could not be found
—continued—
—continued from above—
Subsequent Build Solution:
29>------ Build started: Project: UE4, Configuration: Development_Editor x64 ------
12> AutomationScripts.Automation -> ~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\AutomationScripts.Automation.dll
30>------ Build started: Project: Android.Automation, Configuration: Development Any CPU ------
31>------ Build started: Project: HTML5.Automation, Configuration: Development Any CPU ------
31> HTML5.Automation -> ~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\HTML5\HTML5.Automation.dll
30> Android.Automation -> ~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\Android\Android.Automation.dll
32>------ Build started: Project: AutomationTool, Configuration: Development Any CPU ------
9> Target is up to date
32> AutomationTool -> ~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationTool.exe
29> Target is up to date
To me, it looks like Launcher.Automation, HTML5.Automation, and Android.Automation fail because the OneSkyLocalization.Automation.dll hasn’t been built and it can’t find the OneSkyLocalization namespace when it searches for it.
Subsequent runs work because OneSkyLocalization.Automation.dll already exists before the build begins.
When Build Solution fails the first error is:
37>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "OneSkyLocalization.Automation". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
37>~PATHTOUNREAL~\Engine\Source\Programs\AutomationTool\Scripts\LauncherLocalization.Automation.cs(10,17,10,35): error CS0234: The type or namespace name 'OneSkyLocalization' does not exist in the namespace 'EpicGames' (are you missing an assembly reference?)
—continued—
—continued from above—
After that failure, the OneSkyLocalization.Automation.dll is successfully built:
46>------ Build started: Project: Android.Automation, Configuration: Development Any CPU ------
47>------ Build started: Project: HTML5.Automation, Configuration: Development Any CPU ------
42> OneSkyLocalization.Automation -> ~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\OneSkyLocalization.Automation.dll
45> XLocLocalization.Automation -> ~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\XLocLocalization.Automation.dll
But the build has already failed because it couldn’t find the OneSkyLocalization namespace when it was searching for it.
Subsequent “Build->Build Solution” runs work because the OneSkyLocalization namespace already exists from the previous (unsuccessful) Build Solution / Rebuild Solution.
“Build->Rebuild Solution” always fails because it’s attempting to rebuild everything every time, and fails to find the OneSkyLocalization namespace before it’s been created again; just like a first run of “Build->Build Solution” after a clean install.
Full logs attached below:
First “Build->Build Solution” attempt from clean install of 4.13.1
Second “Build->Build Solution” attempt from clean install of 4.13.1
*Note: “~PATHTOUNREAL~” is a masking string used to hide user data. Within the actual log it is an explicit, absolute path to the UE4 install directory.
First “Build->Rebuild Solution” attempt from clean install of 4.13.1
Third “Build->Build Solution” attempt from clean install of 4.13.1 (first after “Build->Rebuild Solution”)
Notice the error given from “Build->Rebuild Solution” is different from the first “Build->Build Solution”, but again the problem is that “OneSkyLocalization.Automation.dll” cannot be found before it is built:
37>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): warning MSB3243: No way to resolve conflict between "OneSkyLocalization.Automation, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null" and "OneSkyLocalization.Automation". Choosing "OneSkyLocalization.Automation, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null" arbitrarily.
37>CSC : error CS0006: Metadata file '~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\OneSkyLocalization.Automation.dll' could not be found
44> Win.Automation -> ~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\Win.Automation.dll
46>------ Rebuild All started: Project: Android.Automation, Configuration: Development Any CPU ------
47>------ Rebuild All started: Project: HTML5.Automation, Configuration: Development Any CPU ------
45> XLocLocalization.Automation -> ~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\XLocLocalization.Automation.dll
42> OneSkyLocalization.Automation -> ~PATHTOUNREAL~\Engine\Binaries\DotNET\AutomationScripts\OneSkyLocalization.Automation.dll
It is possible that there may be some residual dependencies on my computer between attempts to build the Engine. However, I also built the Engine (4.13.0) on my new-build computer at home this past weekend and didn’t have this issue (though I built the UE4 project, not the entire solution).
It seems as though the various dependencies in the solution are building in a different order for you than they are for me. The automation dependencies appear in my build logs near the top, as they do for you. However, in my case they appear to go ahead and build those dependencies instead of throwing an error as occurs for you. I’ll do some more digging next week to see if I can get to the bottom of this.
In looking closer at the logs I don’t think an external dependency is the issue; it looks like it’s the build order.
Is there a config file or ini that determines the build order, or something like that? I’m wondering what dictates the build order, and why it would be different on different machines building the same project/source.
Hi GigasightMedia,
Sorry for the delay on this issue. I found out today that some of our engineers actually found and fixed this issue a few days ago. There was apparently a circular dependency that could occur between a couple modules when building the Engine, that resulted in this issue. From information that the engineer I was speaking with provided I was able to reproduce the issue by deleting the Engine/Binaries/DotNET/AutomationScripts folder, then building the AutomationTool project. Doing that gave me the exact same error messages that you reported seeing, and building the AutomationTool project a second time completed successfully.
Unfortunately the engineer was unable to provide me with the exact change that they implemented, so I am not sure exactly what fixed this issue. I did try to reproduce the issue in our latest internal version of the Engine using the same repro that I mentioned above and the AutomationTool project built successfully on the first try, so it looks like the issue should be corrected in a future release version of the Engine.
I am still not sure what would cause the issue to occur for you and some others, but not for me unless I took some very specific steps that I do not believe you are taking. That is still something of a mystery.
Sounds good. I assume it will resolve itself during the next source update.
In the meantime, I’ll just not do a full engine rebuild. More an annoyance than an actual problem.
Thanks for working it through with me.
Do you have an ETA on 4.13.2?
Hi outlawhacker,
At this time we have no plans to have a 4.13.2. That could change, but it is unlikely.
Does this mean that we would need to update to 4.14 in order to get this fix? Is there really no way of finding out the fix to this issue? This happens to most people in our team and we needed to apply workarounds for our build servers to not fail because of this.
I am trying to see if I can track down who may have actually put in the change that corrected this issue, at least when I tested on our latest internal build. I had to artificially set up the issue that was occurring normally for everyone else in this post, so I cannot be completely sure that it has been corrected until we release a version containing the fix that you can try.
If I am unable to determine the precise fix, 4.14 should include the changes that allowed my test to work successfully. We have already branched that version, and the first preview should be released soon.
I updated to the 13.2 release yesterday and experience the same issue(s), but apparently with more circular dependencies.
Looking forward to 4.14 
Hey ,
just out of curiosity. Did you ever tracked down the fix and can provide a CL?
We are on 4.13 and do not plan to update in the near future…
Thanks in advice,
Hi ,
Unfortunately I was unable to find any internal tickets related to the issue, so could not determine where it originated or was fixed. That means that the issue was either fixed without a ticket ever having been entered, or I was completely failing in my attempts to find the ticket. I can do a binary search through all of the commits between when this was seen in 4.13 and when I was unable to reproduce it in 4.14 to try to pinpoint where the fix occurred if you need that, but that is likely going to take a while.
Hey ,
thanks for your reply. If you can do this I would really appreciate your effort!
Many thanks,