Compiling project from network drive

Development Getting Started & Setup
, , ,
1

Hi,
I’m having issues opening projects stored on a network drive.
First and foremost, the same projects in the same machine successfully build in visual studio and open in unreal when using a local copy. The problem only arises when the project files are located in our company’s servers.

Opening the .uproject file, i get the

the following modules are missing or built with a different engine version: [project name] would you like to rebuild them now?

error message. If i click yes, i get the

[project name] could not be compiled. Try rebuilding from source manually.

error message.

If I open the visual studio solution first I get the following popup:

An error occurred while creating or opening the C++ browsing database file […].vs[project name]\v17\Browse.VC.db. IntelliSense and browsing information will not be available for C++ projects

(note, i normally get this popup when opening a local project at the same time in two different visual studio instances)

Then if I rebuild the entire solution (Win64) it succeeds. If i start ue from within VS, i get a different error

Unable to start program ‘[correct ue install path]\Engine\Intermediate\Build\Unused\UE4.exe’ The system cannot find the file specified.

Even after the successful rebuild, I still get the first error when trying to open the .uproject file. If I rebuild from VS in the server, and then copy the exact project folder in local, I can open the .uproject without issues.

Can anyone help with this issue? I’m getting quite desperate. I don’t see any reason why everytwhing works with locally stored projects, and everything breaks with projects stored on a network drive.

The closest issue I found is this post from 2015 ( Can’t build C++ project located on network drive - Programming & Scripting / C++ - Unreal Engine Forums; i tried to apply the solution proposed by Rumbleball, but nothing changed.
Also note that making a C++ project unrelated to unreal, and storing it in the server, I can open it in visual studio, compile it and run it without any issue besides the “intellisense can’t open browse.vc.db” warning.

I’m using Visual Studio 2022 and Unreal Engine 4.27, but as soon as I get this to work I’ll have to make sure Unreal Engine 5 works as well in the same environment.

2

Did you find a solution to this issue? I am having a similar issue because I want to compile both Windows and Mac versions of the same project, which are stored on a shared drive from the PC. I really want to make sure I have a workflow, and having to move files its very time consuming!

3

Sadly no. The final “solution” was having a copy on each machine where a given project might be worked on.

In your case however since it’s just you with 2 machines, you may consider storing the project in an external drive and physically connecting the drive to the machine you want to work on. Moving a cable is faster than moving project data across the network :wink:

1 Like
4

That is a shame, but yes moving it via USB is quicker. Thank you for getting back thou :slight_smile:

1 Like
5

First, you have to make sure that you’re granting access to .dll files over the network.

Mac probably won’t notice or care, but Windows flags that extension as “dangerous”, which is what causes the project to always be unbuilt. Depending on your share type (SMB, NFS), you may need to set permissions, including permissions on parent directories.

You may have to turn off all antivirus on windows, because .dll files are often a method of virus activity, and antivirus can often disallow access over network.

You will almost definitely have to map the drive letter. Using the UNC method didn’t work for me.

You also need to add “trust” settings in Visual Studio, if that’s what you’re using. Go to “Tools → Options → Environment → Trust Settings” and add the shares/paths that you’re allowing dll access on.

A simple test (but not the only test!) is to try opening a network-shared .dll in a text editor. If you can’t open it in a text editor, that’s a starting place to debug.

It’s also worth mentioning that Windoze is decidedly case insensitive, where Mac and Linux are usually case sensitive, so using 3rd party libraries (or even your own), you have to make sure that path capitalization is correct, especially in .cs files and #include calls. Many times this is a gotcha where a library has clearly only ever been tested on a Windows system. This also means that your .cs files will need to use correct path separators by using Path.Combine(), although I have seen it work without doing this by always using forward slashes.