#VS 2022 with support for compiling UE and native C++ applications.
1 messages · Page 1 of 1 (latest)
To get a simple C++ Hello World program to compile, I had to uninstall and reinstall VS 2022, as no matter what I tried, it kept failing due to MSVC mismatch and what not.
That, of course, breaks compiling UE, as UE specifically wants an older MSVC version (among other things) than whatever latest is.
I got it working by now again (both), but after (re)installing VS 2022 17.14.16, as well as the following workloads, I've had to fight my way through a few "compile errors" in UE before it started to behave again.
- Workloads
- .NET desktop development
- Desktop development with C++
- Game development with C++
The first errors I encountered were seemingly "random" inside the Engine. I don't have them at hand anymore, but searching the web for them usually points you to the wrong MSVC version (as expected).
So, heading over to the setup instructions in the UE docs, I went back into the VS Installer and additionally selected MSVC v143 14.38, even though the docs don't necessarily say that it has to be the exact version instead of a newer one.
That alone didn't make UE happy, so I went into the BuildConfiguration.xml file and specifically pointed UE to use 14.38.33130 for the CompilerVersion.
I think I can also set this up inside the config files somewhere, but for now that's enough. This resolved the initial errors, but then I ran into the following error.
Error C4756 : overflow in constant arithmetic
A quick search sent me back into the VS Installer, this time to swap out the Windows SDK version from Windows 11 SDK (10.0.26100.4654) to Windows 11 SDK (10.0.22621.0).
Guess "or newer" in the docs doesn't actually mean "or newer" but "this exact version". Again, this resolved the previous error, but then I started facing this error.
Error LNK1181 : cannot open input file 'wininet.lib'
Back to the docs, I checked the version numbers once more, but they seemed correct. Searching the web wasn't helpful anymore, as answers to similar questions were questionably wrong.
I then checked the "Adding Required Workloads" section of the docs, where Epic recommends to tick .NET Multi-platform App UI development, but I'm pretty sure I never had to, so I left that alone.
Below that, they list "Adding Required Components". Most of those I had, minus the Unreal Engine Installer. Not a clue what it does but it after installing it, it removed the previous error with no new ones coming up.
I now expected the Hello World program to be broken again, but it seems to still compile. Maybe a fresh solution/project will break again, but then I at least know it'll be a setup issues in the project and not in VS Installer.
This feels like a bit of a fight I have to say. I haven't really had to use the VS Installer for quite a while.
I also don't know why the original setup, which was able to compile UE, failed to compile the Hello World program, even after installing the latest MSVC and pointing it to use that.
I can only assume that there was more stuff missing, but I have no access to the logs anymore.
can you not just set the msvc ver in the properties of the hello world program?
Second last sentence.
also arguably you can make the buildconfiguration xml choose a specific msvc ver but I forget if that is consistent enough with multip[e installed
You should read the post first I would say :D
one thing I have found is windows api stuff can hurt
I also don't know why the original setup, which was able to compile UE, failed to compile the Hello World program, even after installing the latest MSVC and pointing it to use that.
That alone didn't make UE happy, so I went into the BuildConfiguration.xml file and specifically pointed UE to use 14.38.33130 for the CompilerVersion.
holy I thought I was at the button but discord cut some of it off
mucho texto
(cant complain though, better more text than no text)
I think UE's docs are lacking the point where the versions that are installed by the Workloads aren't working for UE by default.
for me one thing that I had to do was use the vsvars batch script with some msvc things but that was a weird one-off build system that isn't really a console app so I doubt it is of much help
And even when installing a specific MSVC version, one would need to uninstall the other or point UE to use the older one.
I went through the vsvars stuff when I wanted to fix the Hello World program.
Nothing worked. I'm pretty sure somewhere when installing this stuff for UE, it didn't include something that a more standard C++ compile setup needs. Reinstalling VS 2022 + Workloads fixed it instantly.
overflow in constant arithmetic I think is windows api yep you found that already, shit lol
But then you of course go down the rabbit hole of changing all the versions around.
Yeah, I fixed the problems all. It works. Mostly sharing in case others struggle.
Cause there is no good write up I found on google.
I sadly have no idea why I couldn't get the original setup to compile the Hello World program.
I didn't have 14.44 installed and it really wanted to use that. Didn't figure out how to point that to 14.38, so I installed 14.44, but while that removed the "need 14.44" error, it still failed due to some other stuff.
"something" was missing. Maybe I doctored around too much in VS Installer a few months ago.
where Epic recommends to tick .NET Multi-platform App UI development
🤨 wha, epic wants you to install MAUI?
i wonder if thats for mobile platforms or something
But it's somewhat good to know that this works:
- Install VS 2022 Version 17.14.16.
- Install Workloads
.NET desktop development,Desktop development with C++, andGame development with C++. - Install
MSVC v143 14.38(in addition to 14.44). - Install
Unreal Engine Installer. - Change
Windows 11 SDK (10.0.26100.4654)(or whatever is latest) toWindows 11 SDK (10.0.22621.0). - Point UE to use
14.38.33130via e.g. theBuildConfiguration.xml.
- Possibly optional if project got created afterwards or Intermediate got deleted and regenerated. If the log still shows 14.44 when building it might be needed afterall though.
🤨 wha, epic wants you to install MAUI?
Probably, for Mobile, yeah. But they don't explain the reason for it.
Also beats me how this fixed the remaining issue. The tooltip is garbage.
That alone didn't make UE happy, so I went into the BuildConfiguration.xml file and specifically pointed UE to use 14.38.33130 for the CompilerVersion.
While I have only tested this on projects, not the engine itself, I believe this is because UBT is "sticky" to the toolchain. If it has selected an MSVC and built part of the codebase with that MSVC, it will keep using that version even if a preferred version is installed later, until you clear the intermediate (or force it with build configuration)
Yeah, which explains why the original problem with 14.44 being installed later didn't affect UE.
so you shouldnt need step 6 as long as you have the preferred version installed before you build (or clear intermediate)
and yeah the win sdk incompatibility is unfortunate
epic always says "or newer" but the asterisk is the size of the sun
Yeah, but this shit only started with VS 22 iirc.
no
if you set it in build config pretty sure it just forces a rebuild of the stuff already built
oh I see, I misread
I can't recall having so many issues in past versions. Somewhere they dropped the ball in keeping the engine up to date with VS stuff.
intermediate overrules preferred (if preferred didnt exist when intermediate was created)
I wonder if they will fix this with VS 26 and future UE versions.
Wasn't there also a problem a few versions ago with using newer versions of VS itself?
Like, you could use 17.10 but if you updated to 17.14 you were f'd? Or is that cause it also updates the Workloads and Components?
I imagine that was actually msvc latest, engines before 5.7 could not work with 14.40+
and 14.39 was blacklisted
I don't remember anything VS side
I don't get why they didn't blacklist 14.40+ though when it just didn't work (the UBT blacklist will make UBT refuse to build with the tool chain to start with)
actually not sure the exact version it broke maybe .40 worked but .44 does not as you ran into -- I assume some std:: feature stuff
at this rate I might build console apps in something besides msvc just to isolate the madness
cmake time so I can make stuff just work without fiddling around (wishful thinking) 
I so rarely have time to work on something more "bare bones", that I can't even properly work with the whole cmake stuff.
I once tried to read into it, but it quickly grew out of proportion and felt like you gotta know how to use it before learning it...
To get a simple C++ Hello World program to compile, I had to uninstall and reinstall VS 2022, as no matter what tried, it kept failing due to MSVC mismatch and what not.
what does this mean though
in regular SLN land it should have chosen the latest or whatever version you picked in the solution settings
generally what I mean here is having a third party C++/C library I want to try using isolated from unreal and most of them have a "here's how to build our crazy stuff" guide that includes 2-3 ways to build the source
usually 1 of which is cmake being the thing that abstracts away compiler settings/definitions etc
but that might be me describing it poorly because I ampretty bad at c++ build systems
I don't see why a hello world wouldn't compile with 14.38
unless the hello world used coroutines or something
I had VS 17.14 and MSVC 14.38 installed and it consistently asked for 14.44, even after specifying things in the project settings.
And it kept failing even after installing 14.44 but due to other errors, which I don't have at hand anymore.
All I can say is that the exact same project, without changing anything, started working after reinstalling VS and the default Workloads from scratch once.
weird. MS dev tools, they just work! not a complicated mess of spaghetti at all
It was quite annoying to figure out, because the errors lead to the same answers and applying those didn't fix the issue at all, at which point you are just banging your head against the wall.
Reinstalling VS 22 was mostly a "have you tried turning it off and on again" approach.
reminds me of the fact that they install newer patch versions into the initial patch version's folder, because their system for finding build tools is so convoluted and broken that they know installing it to the proper folder would just take the tower of cards down
"You gotta install version X." "You gotta run vsvars." "I fixed this by running vsvars with this specific version." "You gotta change the project settings." "You gotta modify the vcxproj file directly."
etc. etc. Nothing resolved it, probably cause the underlying issue was something not being installed that I wasn't aware of and most people propbably expect to be there.
I wonder if it was because vs installer just failed to install 14.44 properly, or a 14.44 folder was still there so it didn't bother doing it properly
I've definitely seen a need to manually delete MSVC folders after uninstalling versions to prevent them from getting picked up by UBT
though in hindsight the stickiness thing was more probably the cause
seems vs installer isn't very good at reliably installing MSVC, which is great considering it's the only way to do it
also, when I tried to build ue main the other day it insisted on an older patch version and had blacklisted the newer patch version. I'm not sure there's even a way to install older patch versions....