VS2017 Support is incomplete and still relies on previous versions.

I am running into numerous issues trying to use Visual Studio 2017 with UE 4.16 when it comes to compiling the engine from source. Since VS2017 is now officially supported it would be nice to see these issues addressed, be it via a hotfix or at least in the release branch. This is immensely frustrating because working with source is not a fast process at the best of times, and I am losing hours and days to these problems.

It seems as though it is NOT possible to use Visual Studio 2017 with Unreal Engine, unless you have had prior versions of Visual Studio installed beforehand. There are a lot of dependencies in the engine on older versions of VS, so if (like me) you have recently formatted your machine and have a clean install of VS 2017, lots of things will fail. The important point here is that as far as my machine is concerned, the only version of VS that’s ever been installed is 2017.

First problem I’ve run into is that the install guide for VS 2017 on this documentation page is wrong. You NEED to also the .NET Frameworks targeting packs otherwise UBT / UHT etc. will not run.


Next, you need to navigate to D3D12StateCachePrivate.h, and change the following lines because they are not supported in VS2017. There are a multitude of answerhub posts on this:
And More…

This could probably be fixed with a preprocessor macro?

Line 716:

    D3D12_STATE_CACHE_INLINE void FD3D12StateCacheBase::SetPipelineState(FD3D12PipelineState* PSO)


    D3D12_STATE_CACHE_INLINE void SetPipelineState(FD3D12PipelineState* PSO)

Now I’m facing a new issue. I’m using the BuildGraph system to try and make an installed version of the engine so that I can easily work with my own custom builds and also distribute them to other PC’s on my network. I now can’t package the engine into an installed build, because of a dependency on Visual Studio Version 12.0! (VS2013). I’ve just lost about an hour of time to the Automation Tool only to be met with this:

This is probably only the tip of the Iceberg. I have no idea what other dependency issues I might run into ones UAT gets further through the build. At this point the solution would be to first install VS 2013, then 2015, then 2017 again. Far from ideal…

I am getting odd results as well as I only have 2017 installed. I’m not as smart as you and just figured it was something that I was doing, thanks for the detailed information. I think I may need to go back to 2015…


I mentioned this in the discord actually. VS2017 gives a lot of problems and I regret upgrading to this crappy Visual Studio. I have issues like VS crashing, hot reloading messed up etc.

If anyone reading this please don’t even think about upgrading to Visual Studio 2017. 2015 works best as of now.

I have to agree with Satheesh, stick to VS2015 for now (though apparently, you still need to have installed 2013 at some point too :/)

Yeah I tried that first, but it doesn’t install the required .NET packages and doesn’t alleviate the dependency on previous versions. The output above is trying to point directly to a VS2013 folder.

You also can’t build PhysX with 2017 currently because the BuildPhysX.Automation.cs was not updated, it still only supports 2015:

Quite annoying when you try to find what causes some PhysX errors in the log. For being able to set breakpoints in the PhysX code, you need to manually build it. And that doesn’t work with 2017.

I have only installed VS2017 on a fresh install of windows 10 with ue4. I have had zero problems with VS. I am currently using 4.16.1, compiled from source. Also, i never installed the .net packs. Could it be possible that the enterprise edition of Windows 10 has something extra over the other versions? As my work pc is windows 10 enterprise.

Master branch, 5 days ago :slight_smile:

Too late :stuck_out_tongue:

Actually, not really.
Have both installed
We’ve started using to VS2017 to see if it runs ok.
Haven’t had any issues, but then again, we already had VS2015 installed.

And, the PopcornFX SDK is does not work with VS 2017. I just went back to 2015 and everything is working!


Nice… That’s one down!

I can’t agree with this. I also had a fresh installation today and I have installed VS 2017 only and it works perfectly fine. You should know that Visual Studio 2017 ships with less software code than previous versions and that you need to install the Windows 8.1 SDK seperately…

I installed the windows 8.1 sdk before Visual Studio 2017 (though the order doesnt matter) and I use my old project on my new machine without any hitches…

That’s exactly what I did.

I get the feeling that some of the components I was missing, you guys may have installed via other software. Visual Studio 2017 / Unreal were the first things I installed (after obligatory firefox installation) after wiping my PC, and I followed the instructions in the documentation exactly.

Also bear this in mind - I’m building the engine using the Build Graph from Source (I download source, build engine once in VS, then I use the automation tool to build a binary version for distribution). After installing the .NET frameworks the engine would build from source, but I STILL can’t build it for distribution because of the dependencies on VS2013 components.

Additionally, if you try to exclude VS2012 and VS2013 packages from the Source download, then engine will still fail to build. If the engine was truly dependent on 2017, none of these prior dependencies should exist. You can clearly see in the output window above a dependency on VS2013.

Building the UE4.sln works for me with just vs 2017, though I haven’t tried the installed build yet.

VS2017 seems to work for me except for one thing…

I use Enum::Count for static array editor properties because it gets nicely displayed in the editor as named enums as the index instead of ints

So the above worked in VS2015, but in VS2017, I need to do this to make it compile…

… or else I get the error about EButtonState::Count not being an int. But doing so means I lose those enum-named indexes for array entries of that property. Anyone else running into this? Is there a workaround?

If you are using strongly typed enums, the VS2017 behavior is correct. The same error would be returned on Clang.

That’s just one of the less amazing “features” in c++, you have to manually cast enum classes and ints. Someone, somewhere, thought having to write (uint8)YourEnumValue every single time was a good idea.

So basically, switching from VS2015 to VS2017 loses the ability to display an array property in the editor with enum names instead of 0,1,2,3,4?

Enums you see in the editor are UENUMs, those are different from pure C++ enums.

Yep, the above example was for a UENUM(BlueprintType) and not a namespaced C++ enum.