VS 2022 MFC build versions possibly finally solved

Development Platform & Builds
1

I was running into build problems both with UE 5.6.0 and with VS 2022 default MFC App template. After many hours of trying to get just the right libraries installed, and the right path statements in the right place. A comment on one search result suggested that more lib’s are better than fewer lib’s. And so I flipped my thinking around.

In VS 2022 Installer Individual Components, I checked every version of MFC and ATL that was also marked (x86 and x64) and that was not a specialized library and that was also either required by Unreal Engine (ie. 14.38, 17.8) or that was the very latest (ie. 14.44, 17.14) thus supporting the default MFC App template that VS 2022 produces during Create New Project “MFC App C++”. The result was that the default MFC App in VS 2022 started compiling and running.

I was also having trouble with the Unreal Engine 5.6.0 source builds. Although I have not yet had a chance to compile the engine from source or the 200 GB project, which will take many hours. Google AI seems to think that the larger problem is now solved.

Google AI suggested: “Your strategy of installing every non-specialized version of MFC and ATL for 14.38 and 14.44 essentially ensured that all potential dependencies were met, whether a project needed the older 14.38 versions (for Unreal Engine) or the newer 14.44 versions (for the MFC App template). While it might seem like a heavy-handed approach, it can be a practical solution when precise version requirements are unclear or conflicting. It’s highly likely that this also resolved your issues with Unreal Engine 5.6 builds. If the engine’s build process relied on specific MFC or ATL versions that weren’t fully present, installing the complete set of required versions would naturally resolve those issues. The fact that the MFC App template is now compiling suggests a successful resolution across the board.”

1 Like
2

This fixed the build for VS 2022 for MFC App C++ template. The Unreal Engine 5.6.0 source build still has the same errors that existed prior to the library changes. More on this in a bit.

3

I got github 5.6 repository to compile last night. This time with 3 failed builds. I still have to study the errors. I was getting 5 failed builds. But I think that was because I may have been using dev-5.6 from a few weeks ago, and there were actual unfixed bugs in the code. Apparently 5.6 solved at least 2 of those build errors.

I am still confused about the difference between the 5.6 repository and the release repository.

Google AI says: “Numbered branches (e.g., 5.6): Represent the source code for past and upcoming official releases. The branch reflecting the current release (like 5.6 for the current official release) is thoroughly tested by the QA team for stability and reliability.”

Apparently that is not the whole story.

The problem I am trying to solve at present is LiveLinkHub is not populating the Video Format field for the several new webcams that I have. Yet those webcams work in other software and also in my own video frame analysis software. The recommended fixes that I have seen sound like guessing. And I know from programming similar that capturing and processing the video feed is not about hacking a work-around.

I think, at this point, I am going to have to dig in to the LiveLinkHub video camera code to find the answer. My guess is that LiveLinkHub is anticipating a particularly video format (eg. 640x480, 24 bit) and the webcams don’t support the required resolution. And therefore LiveLinkHub simply does not list a format, and does not explain why it did not list any of the video formats that are working in other software.

Digging in at the developer level looks like it may be a requirement to find the answer and to do the things I want to accomplish.

The Epic Launcher binary install seems to work well enough if you limit your goals to environment and character mesh construction and stand alone builds. But, as the environment gets larger and as I try to do more complex stuff, it seems changing over to the source build becomes necessary to figure out why some things don’t work as it seems they should. And in other cases appears to be required, for example: client server multi-player builds.

It was disappointing to find out that UE has a core layer that abstracts the structs and classes away from standard C++. Epic calls it the reflection system. Apparently the reflection system is so that the UE Editor has a generic way of revealing the struct and class members to the Editor user interface.

UE seems to have many problems that are unusually difficult to solve. And I don’t think it is because of code size. I now think it is a result of decisions like abstracting away from standard C++ structs and classes.