Download

Can UE projects be shared between computers if UE installed on different drives?

Unreal Engine -> 4_22
Visual Studio -> 2019

Work Computer -> C:\Program Files\Epic Games\UE_422
Home Computer -> E:\Epic Games\UE_422

Hi all, I have a situation where i have two dev machines. Both computers have UE installed on different drives

Is there a way to successfully manage moving a project back and forth between these two environments? Or will I be forced to my home computer install to C:\Program Files\UE_422 as well?

I started a project last night at home, brought it to work with me this morning, loaded it up on my work computer. Lots of C++ compile errors. Obvious things like not being able to find header files.

I’ve tried poking around seeing if there was a way to re-generate the project on my work, but had no luck. I did manage to somehow loose ALL my C++ header file references in the C++ project settings. Not sure how I did that, but… but it happen.

My project itself is on an external hard drive that connects via USB. This is what I moved between the two projects.

How about source control ?

It’s not a source control issue. More an issue that on one computer I have UE4 intsalled on the “C” drive, on my other computer UE4 is installed on the “E” drive and when I open up my project on a the other machine, all the UE CPP header references are broken.

Because UE hard codes the path, makes it hard to move the project from one computer to another.

The only way I can think is to generate project files as per both the Engine locations and load’em up in the IDE as per the need. Also pay attention where exactly the projectfiles are stored. They are by default stored in the directory containing the top level Engine folder. For instance at your work computer write the command


Engine/Binaries/DotNET/UnrealBuildTool.exe−Project= ‘‘PATH TO PROJECT DIRECTORY/PROJECTNAME.uproject’’-projectfiles

to generate all sorts of project files in the default directory (on your work box).

Hi Cowboy, maybe I’m not fully understanding your post, but I’m not sure this is exactly what I’m hoping to resolve.

What I’m looking for is a way to configure UE to use a system environment variable… Something like you usually see in VS. A variable that might look like $(UE_Source) that would point to the location on a hard drive where all the UE engine source is, so that when building that list of headers, it would build the path based on that variable, rather than what it hard codes…

I guess this would go hand in hand with a way to “re-generate” the solution.

Actually, I just found something interesting which might get me what I’m looking for. A bunch of batch files.
C:\Program Files\Epic Games\UE_4.22\Engine\Build\BatchFiles

As I said, you have to generate project files separately on both the boxes as they contain the information about the appropriate headers and source files (other words, they, project files, do point to the location on hard drive where all Engine source is). I mean that is exactly what UnrealBuildTool does and you can see it as the program with environment variable $(UE_Source) and not hardcoded (if the boot fits!).

Thanks Cowboy, maybe I just didn’t understand what you were saying.

Where the engine is installed doesn’t really matter as long as the proper file associations for .uproject are setup correctly (either by the launcher or by the setup process with an code build). Inside the .uproject file there is a field that is used to determine what which known version of the engine to use for compilation / running. As Cowbow said, you have to run GenerateProjectFiles on each PC so that the engine itself can generate it’s specific solution. In UE4 you shouldn’t be managing your VS solutions yourself, let the tools do it for you.

On a side note, I always suggest adding Perforce to the mix since it makes transferring the source that much easier.

As others have said, assuming you’re using Visual Studio, you should have each computer with a different set of the Visual Studio project files. Don’t commit those to source control.