How do I disable VsHub.exe in the system tray?

Question

Starting Visual Studio 2015 also launches two other executables:

VsHub.exe

and

Microsoft.VsHub.Server.HttpHost.exe<

Answer 1

As xakepp35 mentioned, you can delete the C:\Program Files (x86)\Common Files\microsoft shared\VsHub folder. However, I suspect that updates or other installers will likely try to re-create it.

What I did was shut down all the VS processes. Take ownership of the folder (as admin) and then RAR (ZIP) up the folder and finally delete it (RAR as a backup if I need the files back). Mine is on an SSD so I want to conserve space. Otherwise you could simply rename it and leave it in place.

Then to prevent it being created again, I used an old Win 3.1 trick. Create a text file named VsHub.txt in the C:\Program Files (x86)\Common Files\microsoft shared folder. Then rename the text file and take off the .txt extension leaving a file named VsHub. Since the OS can't create a folder and a file of the same name in the same location, poof, its inaccessible as a folder to VS and its inaccessible and future installers/updaters as a folder either. Then if you need to allow access again in the future, simply add the .txt back on the file and away you go.

Answer 2

According to a Microsoft Program Manager commenting on the Visual Studio Blog commenting on the Visual Studio Blog, it's used to support multi-tool communication across the VS suite. Given how complicated Visual Studio is, I wouldn't recommend anything as harsh as xakepp35's answer (deleting it).

On my Win10 x64 with VS2015 running, while debugging, there's three processes and the total RAM usage is less than 150MB total. Unless you're page-thrashing on a machine with minimal RAM that's not much to be concerned about. Given that you're running VS2015, I'd guess you have 150MB to spare.

Until or unless you find documentation showing explicitly what the Hub is supporting, I'd recommend leaving it be. In my experience, Visual Studio installs are far too easy to break.

Answer 3

This seems to be a communication Swiss Army knife for visual studio as per @sraboy's answer. It is used during debugging to display performance information about the running process, but also to send telemetry to Microsoft about the project you're working on. You can build and step through code fine with it disabled (at first glance).

Removing, renaming or blocking the vshub process creation with AV will break the performance tracing I mentioned. Losing vshub improves privacy while using Visual Studio as it communicates with vortex.data.microsoft.com, passing information such as solution & project GUIDs along with your account id. Below is a screenshot from fiddler intercepting the HTTPS data.

Blocking access at network level helps with privacy, but it will not address your resource usage issue. I would consider the latter as a normal overhead of running Visual Studio.

For your use case, you can probably get away with some form of disabling (blocking instantiation with your antivirus software is probably the cleanest approach), but it may support additional functionality I haven't figured out yet.

Answer 4

One of the reasons why Visual Studio tries to connect online seems also that, by default, search online for updates for both Visual Studio and its extensions.

Also, Visual Studio includes a version of Internet Explorer within its core so that webpage (and extension) can be downloaded live. In other words, it acts as a browser as well and as we all know... Microsoft is pretty keen on checking its users' data and usage of its software.

There are plenty of online functions in the menu Tools → Options. (To be honest, I do prefer MonoDevelop even with its flaws.)