Some troubles with VS after compiling the engine from source

I’m having some issues after compiling the engine from source:

  • Compiling any game in VS launches the Project Browser instead of the game itself.
  • If I click the “Open Visual Studio” option inside the editor I get a message that says “Could not open Visual Studio 2013 for project [the path of the project]”.
  • When I add a new class to the project and the editor ask me if I want to edit the code if I click “Yes” nothing happens.
  • Hot Reload recompilations are significantly longer than before, from 15-20 seconds to 2 minutes.

Non of these issues are present when I use the binary version of the engine.

I have Windows 8.1 and VS 2013 Express.

Hi ,

What version of the Engine are you using? I ran some tests with the latest release version (4.4.3) and was not able to see the last three issues that you mentioned.

The first issue that you bring up is actually expected. Whenever you create a code project using the Engine built from source code, the code for the Engine is included in the solution, and the Engine project is set as the startup project. If you press F5 to start the project in the debug environment in Visual Studio, it actually runs the Engine project, which gives you the Project Browser. If you want to load directly into your game project, you have a couple options:

  1. Right-click on your game project in the Solution Explorer, then go to Debug → Start new instance.
  2. Right-click on your game project in the Solution Explorer and select Set as Startup Project, then press F5.

Both of these options will open your game project inside the Editor from within Visual Studio’s debugging environment. The second option provides a more “permanent” solution, the first one you would have to do every time you want to debug your game project.

If you are used to using the Binary version of the Engine, the only project included in the solution when you create a new code game project is the game project itself, so pressing F5 will open the game in the Editor. This is one of the differences between the Binary and source code versions of the Engine.

Hi , thanks for your answer.

Ok, the first “issue” is solved now (sorry for that), but the others are still present. I noticed two small changes, though.
Now if I click “Open Visual Studio” and VS is already open and debugging, it brings the VS window to the top. And if I add a new class and I choose to edit the code, it opens a new instance of VS in “text editor mode” (there’s no solution explorer neither compilation/debugging options) with the new created files.

I didn’t put it on the first post, but when I try to open VS and I get the “Could not open Visual Studio 2013 for project [the path of the project]” message, the output log throws this warning several times :

LogVSAccessor:Warning: Couldn’t access module table

I’m using 4.4.2 (I forgot to download 4.4.3 from Github before my subscription ended) and I also had the same problems with 4.4.1.

I will do some more testing with 4.4.2 and 4.4.1 to see if I can reproduce the issues that you described. Were you running the Editor through Visual Studio’s debug environment when you saw all of these issues? What solution configuration do you have set in Visual Studio? Do you see the same results if you open the project directly instead of going through Visual Studio?

I get the same results no matter if I launch the editor from VS or by opening the .uproject.

The only difference is that if the solution is open in VS (no matter if it’s debugging or not) when I click “Open Visual Studio” the editor minimizes and doesn’t throws the “Could not open Visual Studio 2013 for project” message (forgot what I told you about the editor bringing VS window to the top, it just minimizes the editor window), but still throws the LogVSAccessor warnings.

I’m using the Development Editor Win64 configuration in VS.
I will try setting it to DebugGame Editor and Win32 to see what happens.

I also have this patch installed :

Maybe I should try to reinstall VS ?

I am still having some trouble reproducing some of these issues. Let me detail what I am doing, and if you can point out where you are doing things differently, that would be very helpful.

  • Launch 4.4.2 built from source code.
  • Create new project using the Basic Code template.
  • Build the project in Visual Studio.
  • Close Visual Studio and double-click on the new project’s .uproject file.
  • When the project opens in the Editor, go to File → Open Visual Studio.
  • Visual Studio opens normally.
  • Close the Editor.
  • Open the project using Visual Studio’s debug environment.
  • Minimize Visual Studio.
  • In the Editor, go to File → Open Visual Studio.
  • The Visual Studio window comes up again.
  • Close the Editor and Visual Studio.
  • Double-click on the .uproject file to open the project in the Editor.
  • Go to File → Add Code to Project
  • Create a new Actor Class.
  • Click Yes to edit the code.
  • Visual Studio opens normally.
  • Close the Editor and open the project in Visual Studio’s debug environment.
  • Go to File → Add Code to Project
  • Create a new Pawn class.
  • Click Yes to edit the code.
  • Click Reload All in Visual Studio and Yes to stop debugging.

I also tried doing some hot recompiles with the source version of 4.4.2 and the binary 4.4.3 and the binary did seem to be a little bit faster.

Reinstalling Visual Studio shouldn’t hurt anything, but it might be helpful if you could try following the steps I outlined above exactly to see if you see different results before you try reinstalling.

I tried different solution configurations, reinstalled VS and recompiled the engine and I have the same problems.

I recorded a video following your steps, so you can see exactly what’s happening :
https://drive.google.com/file/d/0B6iZbdFM0CSGT1pyVGRmRkg2NVk/view?usp=sharing

I could live without opening VS from UE4, that’s no problem, the real problem are the hot recompilation times. For me is not a little bit slower, is 6 times slower in the best case.

EDIT:

I tried with 4.5.0 preview and the bad news is that I’m having the same issues.

The good news is that the new hot reloading from VS is super fast, almost as fast as binary. :slight_smile:
Hot reloading from the editor tends to be very fast too as long as I’m not debugging, but sometimes freezes the editor (Similar to when an application enters into an infinite loop).
Hot reloading from the editor while debugging is as horrible as before.

Thank you for the video. I have a much clearer idea of what you are describing, now. Just to clarify, everything works normally when you are using the binary version of the Editor, correct?

Could you please download this file and place it in a new empty folder on your desktop. Remove the .txt extension and run the file. It will create a new info.txt file in the folder. If you could upload that file, it will let me take a look at the VS environment on your computer. I don’t expect to see anything unusual, but it should let me rule out a couple things.

Just to clarify, everything works normally when you are using the binary version of the Editor, correct?

Yes.

Here’s the file.

Thank you. :slight_smile:

EDIT: Sorry, I misread your last post. If I put the .bat file on my desktop it creates the info.txt I just posted.

If I put it on a new folder on my desktop it creates this file on the desktop. (the file doesn’t have extension by default, I added the .txt so I can attach it to the post).

If I open the .bat file from the command line, it says:

C:\Users\Miguel\Desktop\Nueva carpeta>17559-get_vs_environment.bat
Variable de entorno VS120COMNTOOLS  carpeta\info.txt no definida
El sistema no puede encontrar la ruta especificada.
El sistema no puede encontrar el archivo especificado.
"vsvars32.bat" no se reconoce como un comando interno o externo,
programa o archivo por lotes ejecutable.
El sistema no puede encontrar la ruta especificada.
El sistema no puede encontrar el archivo especificado.
"vcvarsx86_amd64.bat" no se reconoce como un comando interno o externo,
programa o archivo por lotes ejecutable.

Was that what you were looking for ?

The first one was the file I was looking for. Thank you. It doesn’t look like there is anything there that could be causing any problems.

Would you be able to provide the log file for your project? Open a project and try to open Visual Studio from the Editor a few times, then close the Editor and go to ..\Saved\Logs and find the most recent log file. If you could please make a copy of that file, add .txt to the end and upload that here, that would be great.

If you could also provide the most recent log for the Engine as well (located in your Engine\Saved\Logs folder), that would also be helpful.

Here they are :

Hi ,

I am very sorry for taking so long to get back to you. I had lost track of this post. Is this issue still occurring for you?

Hi . I’ve been testing this today and seems like it’s working fine on 4.6.1.
I have recently switched to VS Community Edition, I don’t know if it’s related.
Anyway we can mark this as answered I suppose. :slight_smile:

I am having the exact same issue as described here in with VS 4.18.1 and VS 2017, can anyone help? I recently had to update everything after a crash and I finally got it working yesterday, but today this happened. Visual Studio and the Unreal build are fresh.
EDIT: I was just able to briefly fix it by rebuilding the engine, worked fine for a few hours after that, but its back up to its shenanigans again.

Hi BaconGaming97,

Sorry for not getting back to you sooner about this. Are you still having trouble with using Visual Studio 2017? Due to the more modular nature of VS 2017, getting it set up correctly to work with the Engine can sometimes be tricky. Please take a look at our documentation on setting up Visual Studio for UE4 to see if that helps with some of the issues that you were experiencing. If you are still experiencing issues, it may not be an actual bug with the Engine. Please feel free to create a new post on the AnswerHub or the forums to get additional help. If you believe that this is a bug with the Engine, please visit our Report a Bug page and fill out the submission form there with as much information as you have available.