Win64 Target Binaries Not Found

Hey all, I have a project that I upgraded from UE 4.26 to UE5.0EA and when trying to package for Windows I get the following message.

The Binaries for this Target Platform are not currently installed, would you like to use the Launcher to download them?

The odd thing is I tried to package the Ancient Valley sample and it worked with no problem. I checked the DefaultEditor and DefaultEngine ini files to see if there was anything it was reading that wasn’t changed as part of the conversion but I can’t find anything obvious.

The other piece of info is that it see’s that I have Windows SDK 10.0.18362.0 installed, so it should be using that??

image

Kinda lost as to what else it could be, I did also delete the BuildConfiguration.xml in the roaming folder for UE and let it regenerate that. In all cases it still fails to package my project, but Ancient Valley has no problems.

Any help on this would be greatly appreciated.

Exactly same issue here!

Any progress so far?

So far nothing I’m afraid, I’ve tried only having the latest Windows SDK and only that one installed but still gives me the same issue.

I’m converting another project I have that was recently updated to 4.26 to UE5_EA, will see if I still have the issue on that one.

May not give me an answer, but potentially lead to something odd happening :confused:

I’m currently getting the same issue with Unreal Engine 5 ER2. I believe that you need a very specific install of Windows SDK and .NET for Win64 builds. I’ve been trying different variations using the Microsoft Visual Studio Installer “Modify Install.” But I’m still getting “Binaries Not Found, do you want to use the Launcher to Download them”

Well, I thought so too, as I did the same to download specific Win 10 SDKs and ended up uninstalling the earlier versions and only having the latest installed.
But now I’m running into a new issue, which means maybe I made progress?

I get an issue with builds in trying to find InputCore.generated.h, even though this is omitted from my {project}.h file even when it was included the problem still happened, even after running the verify files for UE5 ER2 from the launcher.

It’s super weird, this just doesn’t happen with the valley of the ancients project and builds fine. So I’m wondering if it’s something to do with an ini setting that is no longer needed for UE5 or causing some conflict.

I took a bit of a break in trying just so that I can focus on making the game, but I guess I’ll be going back to trying some things soon.

As at least, I’m getting something different than “Binaries Not Found”.

Same issue since last night. Packaged and ran my project fine, went to bed leaving the editor on. When i woke up I did some minor changes like moving directional light and tried to package again, then i got the error.

That’s more annoying, since you had a point at least where packaging worked :confused:

Was it a project that was upgraded from 4.26?

No, project entirely created in 5 EA 2, suddenly stopped working, I even blew the entire workstation and reinstalled everything but now im still getting the same error, with all my projects.

Something seems to have changed when it comes to 3rd party libs.
I’m using:
The internal dotnet runtime and 3.1 core inside the binary UE 5 EA from the launcher with DOTNET_ROOT environment variable, .net framework 4.8 sdk
Visual Studio 2019 14.29.30136 toolchain MSVC\14.29.30133) and Windows 10.0.19041.0 SDK
This is what I used to successfully package my project before.

UATHelper: Installing Sdk (Win64): Platform indicator Windows is an invalid platform, skipping
UATHelper: Installing Sdk (Win64): Installed Sdk validity:
UATHelper: Installing Sdk (Win64): Win64: (Status=Valid, Installed=10.0.19041.0, AutoSDK=, MinAllowed=10.0.00000.0, MaxAllowed=10.9.99999.0, Flags="InstalledSdk_ValidVersionExists")
UATHelper: Installing Sdk (Win64): Win64@DESKTOP-SBH24T9: (Name=DESKTOP-SBH24T9, Status=Valid, Installed=10.0.19043.0, MinAllowed=10.0.0.0, MaxAllowed=, Flags="Device_InstallSoftwareValid")
  Building 14 actions with 12 processes...
    [1/14] SharedPCH.Engine.ShadowErrors.cpp
    C:\Program Files\Epic Games\UE_5.0EA\Engine\Source\Runtime\InputCore\Classes\InputCoreTypes.h(10): fatal error C1083: Cannot open include file: 'InputCoreTypes.generated.h': No such file or directory

Verifying the engine did not help further than resetting it so you can still try a shipping build but fails again with the same errors about binaries not being available for win64

Thanks for sharing that info, seems like the exact issue that I have as well with InputCoreTypes.generated.h.

Problem with the InputCoreTypes is I’ve seen it in quite a few places, so it’s probably not as simple as pulling it out everywhere.

Have you tried building the valley of the ancients sample? Because that seems to work for me with no problems. Even recently when I tried it was fine.

At this point it may be worth trying some the github source, building the binaries and running a project, see if that works. I can see in GitHub that it’s there InputCoreTypes.h so it may be missing somewhere in the released binaries :confused:

Just taking somewhat educated guesses at this point :confounded:

hmm, I’ve now managed to atleast stage (no packaged pak files, not cleaned etc) my project by verifying the engine through the epic launcher and then using the project launcher tool to launch.

This actually succeeded and I can find a working build in my saved/staged builds. As long as I don’t try to actually press package, it seems to work. I haven’t changed my installed sdk’s or anything so it would seem the engine can actually package… it just thinks it can’t when you use the package option, or when you try to update sdk’s through the update device option in the same menu.

If I press package or cook it will still error out and stop letting me even try to launch a shipping configuration, forcing me to verify the engine again.

I have not tried building the ancients sample simply due to space constraints, but I assume it would fail aswell for me unless I only used the project launcher. Even a blank project fails the same way for me now so it doesn’t seem project specific to me.

I want to get it working from within the editor but it seems to me, working through command line, I might be able to solve this.

Interesting it works for you via the project launcher, I hadn’t thought about trying that way, I’ll give it a go myself also.

It works for building via the command line? Doesn’t Unreal do that through the editor via RunUAT?

Yes it does but no it doesn’t work packaging via command line passing the same options currently.

Figured there might be some options to pass that might help the issue, like verbose maybe, unfortunately I’m pretty new to unreal engine specifically. Somehow its not recognizing windows as a valid target platform and I want more verbose output as to why.

Not recognizing Windows as a valid platform sounds more troubling :confused:

Have you checked the Turnkey manifest in Engine/Build/Turnkey?

Turnkey Source ← Here’s an example from the repo. It’s missing in the binaries from the Epic Launcher, I added them in the hope that maybe it’d help, potentially it’d help with you.

I was getting errors about Turnkey during builds so thought maybe it’d lead to something, it didn’t :weary:

1 Like

after alot of tinkering I was able to get rid of the missing binaries error but was instead presented with an assert isValid() eroor in sharedpointer.h which I could fix by removing the quixel plugin. Im finally packaging!

current setup


together with a manual .net core runtime image

No custom environment variables (so no DOTNET_ROOT)

Some further testing. I enabled the plugin again in my project and now im back to missing win64 binaries. so quixel is the cause for all of it!

1 Like

DUDE!! THANK YOU!

This is such an amazing find!

I disabled the plugin and was able to build also, didn’t get the error.

I did another test and changed the SupportedTargetPlatforms in the uproject file so that Win64 isn’t a targetplatform.

So it looks like this: image

And this works also, I don’t know if it’s a fluke, but means at least if using Quixel bridge within the editor you don’t have to disable the plugin completely to build and lose that functionality.

2 Likes

Awesome, that helps me aswell!

I’ll inform quixel about this

1 Like