Alternative to UnrealBuildTool.GetUProjectPath() in 4.11


My question is fairly simple, is there any alternative to the now removed method UnrealBuildTool.UnrealBuildTool.GetUProjectPath() ?

My build files rely on this to perform pre/post compile and clean operations on various folders based on the project (root) directory. I could work around the issue by using relative paths to the module but this it would break if I even move the module in the folder hierarchy. Basing on the project path is much more reliable.

I have tried:
UnrealBuildTool.UProjectInfo.TryGetProjectForTarget (fails to compile, symbols not visible)
UnrealBuildTool.UProjectInfo.TargetToProjectDictionary(fails to compile, symbols not visible)

Any help would be appreciated. I believe this functionnality is important and if there is no way to access the uproject path, I would love to know the reasoning behind removing this functionnality.

EDIT: Usage example:

using System;
using System.IO;
using UnrealBuildTool;

public class YourLib : ModuleRules
    public string GetUProjectPath()
		//return UnrealBuildTool.GetUProjectPath(); //Now deprecated :(
		//Assuming Source/ThirdParty/YourLib/
        return Directory.GetParent(ModuleDirectory).Parent.Parent.ToString();

    private void CopyToBinaries(string Filepath, TargetInfo Target)
        string binariesDir = Path.Combine(GetUProjectPath(), "Binaries", Target.Platform.ToString());
        string filename = Path.GetFileName(Filepath);

        if (!Directory.Exists(binariesDir))

        if (!File.Exists(Path.Combine(binariesDir, filename)))
            File.Copy(Filepath, Path.Combine(binariesDir, filename), true);

    public YourLib(TargetInfo Target)
		Type = ModuleType.External;


		// Compile and link with YOURLIB

		PublicIncludePaths.Add(ModuleDirectory + "/include");
		PublicAdditionalLibraries.Add(ModuleDirectory + "/lib/YourLib.lib");
		CopyToBinaries(ModuleDirectory + "/lib/YourLib.dll", Target);

Hello Kryofenix,

After a brief search, I came across this Answerhub post that may assist you:

Let me know if that helps, and if not we can continue to try and find a solution for you.

Have a great day

This does not help, as it describes a c++ method to be used in the editor plugin code (or maybe game code?).

I am talking about the unreal build tool c# code here, and that method was available (and very useful indeed) before 4.11.

The only workaround I currently have is to use a hardcoded relative path to my ModulePath, but it is not the best for maintenance reasons, i.e. if I move my module I would now need to adjust my Build.cs file, whereas by using a method such as GetUProjectPath, my Build.cs file was valid no matter where my module was placed.

If anything I would love to know the reasoning behind the removal of this method.

Here is an example of why the UProjectPath can be useful, and how I am currently working around it (I answered this question)

Could you adapt some of the code in Engine/Source/Programs/UnrealBuildTool/System/UnrealBuildTool.cs to your needs? It seems to do some path-munging logic around line 520.

I’m not sure why this was accepted as an answer.

I was looking at this code as a way to work around the missing method but :

  • It is somewhat complex logic that extracts the parameter from the command line arguments
  • While i technically can adapt this, there’s nothing to say that the command line parameters won’t change in the future which will void my implementation
  • After parsing the command line, the UBT is clearly aware of the project’s file location, and could easily expose it again.

I would still be interested in knowing the reasoning behind removing this method, as it was used and useful. If the UBT is not supposed to expose project files for some reason (such as maybe handling multiple project files at once or some valid reasons like that), then it’s better to know, and it’s better to know how UE4 devs intend us to work with the system they provide. It is currently very difficult to set up pre/post/clean build steps such as cleaning binary files or copying dlls in the binary directories, never mind something more complex.

Finally, I believe it is best to deprecate a method for a few versions before removing it as well. It gives us time to adapt, but also this process encourages devs to providing alternative API to deprecated methods.

I am currently investigating this issue, and I will respond as soon as I have new information.

After having a discussion with our developers, there is no alternative to GetUProjectPath(). It was not meant to be public, which is why it was removed, and it is not meant to be accessible from those build.cs files.

Attempting to copy files from the build.cs files should not be done. If the class is being instantiated, this does not necessarily mean that it is going to be built.

Have a great day

Thanks for taking the time to investigate this issue. This is the kind of answer I am looking for. I will open another question about pre/post build steps and the intended way to do that.