UE4 opening new instances of Visual Studio

Development Pipeline & Plugins
, , , , , ,
1

When I create a new C++ class, UE4 opens an additional instance of Visual Studio and I get the following notifications: “Conflicting File Modifications Detected” in the already open Visual Studio and “Found a suitable location for browsing database and IntelliSense files” in the newly opened one, creating a new BROWSE.VC file in AppData\Local\Temp\VC++\BROWSE.VC-1b23fdfe, then both instances start recompiling.

So far I have tried rebooting, reopening, deleting the project files, starting a new project, and reinstalling UE4.

Someone had a similar problem in 2014 Additional instances of Visual Studio opening on create classBug - C++ - Epic Developer Community Forums
and they fixed it by uninstalling a previous version of Visual Studio they had on their computer. I only have “Microsoft Visual Studio 2017”, a 64bit redistributable for 2008, 2010, 2013, 2017, and a 32bit redistributable for 2010, 2013 and 2017. The 2008 and 2010 redistributables were on my before installing UE4, everything else was installed through the UE4 installer.

2

Hey Immen-

This is a known issue that has been reported here: Unreal Engine Issues and Bug Tracker (UE-51608) . You can track the report’s status as the issue is reviewed by our development staff. Please be aware that this issue may not be prioritized or fixed soon.

Cheers

3

I really hope it will get some more priority and be included in the next hotfix. On slower PC’s this all takes quite a while and when having to add multiple classes the amount of time requires for simply adding C++ classes quickly adds up to enormous amounts of time/annoyance.

Actually it opens TWO additional new VS instances (at least for me with VS2017 and running the UE4-editor through VS2017 on Windows 10 Pro):

  1. Add a new C++ file in editor
  2. The new VS2017 instance throws an Intellisense error. Close the new VS2017 instance right after it displayed that error.
  3. The UE4-editor now opens yet another VS2017 instance (only containing the newly added C++ file, not the project I believe)
  4. Close this third VS2017 instance and the editor indeed has a stuck “Loading Visual Studio” toast message.
  5. Give focus to the original VS2017 instance and click the option to reload the project there from the popup because the project has been changed outside of this VS2017 instance (this will close the UE4 editor instance)
  6. Optionally: Relaunch the UE4 editor by pressing F5 to build&launch it.

Now you can finally work with the new file. Especially on slower PC’s or when I need to make an interface + baseclass for the actual class I need… Takes about 12 minutes on the slowest we have here…

Also I’m not sure how smart it is to ignore the stucked toast message before adding another file. I usually just restart the whole thing to be safe. But it eats my sanity so now and then.

4

I mentioned on the other thread with this issue:

One of our team found a work around/fix that can be added to an Engine Source build.

EngineFolder/Plugins/Developer/VisualStudioSourceCodeAccess/Source/VisualStudioSourceCodeAccess/Private/VisualStudioSourceCodeAccessor.cpp

Line 224 -

 if (Filename == InSolutionPath)

to

 FString AbsoluteSolutionPath = FPaths::ConvertRelativePathToFull(InSolutionPath);
 if (Filename == InSolutionPath || Filename == AbsoluteSolutionPath)
5

I’ve been working on tracking down the root cause of the issue and think it’s not about operating system installs at all. Is your Unreal engine install on the same hard drive as your project file is?

6

Yes they are both on the same physical HD and on the same partition as well. I use the binary version of UE4 so I did not test that workaround that posted.

Since UE4.18.1 the bug is gone for me :slight_smile: EDIT: this is not the case, it was temporary for some reason.

7

Unfortunately 4.18.1 doesn’t seem to have resolved the issue for me (and I’m not sure how it resolved it for Napoleonite), but I have created a pull request which fixes the issue on 4.18 and discovers the root cause for why it suddenly started happening + repro steps. I’m adding this as a reply here so that it can hopefully be associated with the Unreal Issues page to save a Epic developer from having to go through all of the research I did when looking to resolve the issue. The pull request can be found here.

8

I must stand corrected, the bug is indeed still there.

It seems that it does not bug 100% of the time (at least for me). Some classes do not start a new VS2017 instance. I just added 3 new ones and 2 of those started new instances and 1 behaved normally.

9

I’ve found way to work around it.
If you set drive of path of engine and project differently each other, you can avoid this issue.
(Example: Engine Install Path: “C:\UE4.18”, Project Path: “D:\MyUnrealProject”)

10

This workaround works for me.

4.17.2 works fine out of the box.

4.18.1 does not work out of the box. Engine opens additional instances of Visual Studio; solution files / headers are not automatically opened, “Loading Visual Studio 2017” -prompt stay on for all eternity.

However, if the drive path of the engine and the project are different, then it works properly.

11

For me this doesn’t solved the problem.

12

Just add an option to disable the editor from ever opening Visual Studio. I can’t think of a single reason why I’d want to double-click on a random place in blueprints and have it open Visual Studio…

13

How do i set the engine path for a project?
Or do you mean that i have to have UE installed on one drive and then put my projects on another drive?

14

The latter, put them on separate hard drives (or see if you can play with symlinks, no guarantees there)

15

I found this thread because of this ridiculous problem. It would take an Epic dev 15 minutes to give us a checkbox somewhere. Then double-clicking (by accident, always) wouldn’t “load” VS. I put load in quotes because it always opens a new VS instance and takes 5 minutes before failing to bring VS to the relevant source code (making it even worse than if it actually worked).

16

For anyone who has the Github source version of UE4 and wants to disable this entirely, you only need to edit one line.

I’m using the “VisualStudio” accessor so I changed:

FVisualStudioSourceCodeAccessor::CanAccessSourceCode()

In:

Engine\Plugins\Developer\VisualStudioSourceCodeAccess\Source\VisualStudioSourceCodeAccess\Private\VisualStudioSourceCodeAccessor.cpp

Note: there are other accessors in the source – which one you need to change depends on what the editor is set to use (i.e. “VisualStudioCode”).

I changed:

return Locations.Num() > 0;

to:

return false;// Locations.Num() > 0;

…and I can double-click nodes all I want but nothing gets opened in VS. The only side-effect is a weird error message in the output log.

17

Update: No that isn’t good because then I can’t build a game from the editor. But I think I’m on the right track…

18

I think I’m going to stick with this solution and build the game from the Frontend tool.