UE 4.18 VS 2017 Unavailable after VCS checkout

I just created a new Subversion repository and created a blank C++ project using a freshly updated 4.18.3 that I compiled from source. I ignored the Binaries, Build, DerivedDataCache, Intermediate and Saved folders and committed the blank project to Subversion.

After checking it out to another computer, generating VS project files and opening Visual Studio, I couldn’t see any of the project files. It had “(Unavailable)” next to the UE4 and project branches and said the project files couldn’t load. If I tried to compile it, it complained about some missing UE4.vcprojx (or something like that) file from the Intermediate folder.

Actually this might not help you. You mentioned you’re generating the project files. Not sure, I think I need some more information - any output error messages?

Hey, I think I know what you’re doing wrong.

You’re supposed to ignore all the VS project files. Even the .sln. See the link below on what you should be ignoring.

After downloading a copy of your project, right click your .uproject and generate the Visual Studio project files.

A new, community-hosted Unreal Engine Wiki - Announcements - Unreal Engine Forums (I know it’s git but the concepts apply to SVN)

Hey, thanks for the response! I followed this document:

Except I put the repo on a remote CentOS box and I’m using svn from the command line with svn+ssh, but none of that should make a difference.

This is the way I’ve been doing it since between 4.14-4.17 and I haven’t had any issues. I’ll try it again but leave the .sln file out to see if that makes a difference. Thanks again!

Okay, without the .sln file, after generating VS project files and opening VS, the files all show up and it builds fine but it won’t run. This is the error I get. Again, this is just a blank C++ project, no starter content or plugins, etc.

1>------ Build started: Project: ShaderCompileWorker, Configuration: Development_Program x64 ------
1>Using 'git status' to determine working set for adaptive non-unity build.
1>Target is up to date
1>Copying G:\TroubleSim\UnrealEngine\Engine\Binaries\Win64\ShaderCompileWorker.exe to G:\TroubleSim\UnrealEngine\Engine\Binaries\Win64\XGEControlWorker.exe
1>        1 file(s) copied.
1>Deploying ShaderCompileWorker Win64 Development...
1>Total build time: 0.53 seconds (NoActionsToExecute executor: 0.00 seconds)
2>------ Build started: Project: UE4, Configuration: Development_Editor x64 ------
2>Performing full C++ include scan (hot reloading a new target)
2>Using 'git status' to determine working set for adaptive non-unity build.
2>Creating makefile for hot reloading UE4Editor (no existing makefile)
2>Compiling game modules for hot reload
2>EXEC : error : One or more of the modules specified using the '-module' argument could not be found.
2>D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.MakeFile.Targets(44,5): error MSB3075: The command "G:\TroubleSim\UnrealEngine\Engine\Build\BatchFiles\Build.bat UE4Editor Win64 Development -waitmutex" exited with code 5. Please verify that you have sufficient rights to run this command.
2>Done building project "UE4.vcxproj" -- FAILED.
3>------ Skipped Deploy: Project: ShaderCompileWorker, Configuration: Development_Program x64 ------
3>Project not selected to build for this solution configuration 
========== Build: 1 succeeded, 1 failed, 2 up-to-date, 0 skipped ==========
========== Deploy: 0 succeeded, 0 failed, 1 skipped ==========

No worries! Hopefully we’ll work it out.

This module issue pops up for some people and it’s always a different solution. Some have has luck doing a clean build\rebuild in VS.

Unlikely but do you have any weird modules in your .build.cs? I have : PublicDependencyModuleNames.AddRange(new string[] { “Core”, “CoreUObject”, “Engine”, “InputCore” });

It’s interesting as just a few days ago I created a new blank C++ project and haven’t had these issues. I’m on 4.18.2 (source build) though.

I’m not sure what was happening the second time. I blew away the engine and repository and started over. This time, I ignored the .sln file and the .vs folder and it appears to be working as expected, at least on Windows, but that’s another story. I think that’s what was causing the problem. Thanks!