Starting Visual Studio 2015 also launches two other executables:
VsHub.exe
and
Microsoft.VsHub.Server.HttpHost.exe<
Something no one's mentioned above...
According to my firewall log, VsHub.exe, Microsoft.VsHub.Server.HttpHost.exe, and Microsoft.VsHub.Server.HttpHostx64.exe all try to communicate online.
Addresses I saw to which there were outgoing connection attempts included 191.236.194.164 (Microsoft Azure, Wichita Kansas) and 23.102.160.172 (Microsoft Azure, Redmond Washington).
I realize "modern" software is supposed to be cloud-integrated, but...
As one who does not require anything from Microsoft Azure servers, and who is legitimately concerned with privacy and not leaking any part of what I'm working on to the outside world, I'd really like A) to have a way to choose not to run these programs, or B) be provided with settings to limit their chattiness online. Yes, the firewall blocks the connections, but that's a last resort.
Just a simple checkbox, "[ ] Contact Microsoft Azure Servers" would be nice. Whether that would mean not running the programs in question or just having them not make the online connections isn't of consequence to me. I guess from a resource perspective the former would be better as it would use fewer resources.
As a rule I wouldn't propose to change the files in an installed application's suite of files, but as I have a virtual machine environment within which I can test changes to Visual Studio 2015 without much consequence (snapshots are wonderful), I tried altering the permissions (to remove inheritance then disallow Read and Execute for Users) on these three files.
Voila, no more VsHub applications running, trying to contact remote systems.
Visual Studio comes right up. I'm not seeing a downside here.
-Noel
For those of you who want to preserve VSHub and still be able to use Fiddler you can setup a Filter in Fiddler with the following setting:
Request Headers > Hide if URL contains =
REGEX:localhost:\d+\/vshub\/
EDIT - you probably want to add this too:
Hosts > Show only the following Hosts: =
localhost;
in order to omit vortex.data.microsoft.com
etc.. requests
It's needed for BrowserLink, the Diagnostics window, Intellitrace.
I sometimes need these features, but only have 8 GB of RAM. I'm usually at 90-95% usage so I created a batch file to toggle VSHub on and off by renaming the folder and creating a symlink to an empty folder with dummy files.
Shutdown Visual Studio before running.
@echo off
goto CheckVsHubRunning
:KillVsHub
echo Killing VsHub Process
taskkill /IM VsHub.exe /T /F
TIMEOUT /T 3 /NOBREAK
:CheckVsHubRunning
ver > nul
tasklist /FI "IMAGENAME eq VsHub.exe" | find /I /N "VsHub.exe"
if "%ERRORLEVEL%"=="0" goto KillVsHub
if "%ERRORLEVEL%"=="1" echo VsHub is not running.
echo.
PUSHD "C:\Program Files (x86)\Common Files\microsoft shared"
IF NOT EXIST "VsHub.original" (
echo Renaming Original VsHub folder.
RENAME "VsHub" "VsHub.original"
)
IF NOT EXIST "VsHub.dummy" (
echo Creating Dummy Folder and Contents
mkdir "VsHub.dummy"
copy NUL > "VsHub.dummy\1.0.0.0"
copy NUL > "VsHub.dummy\ServiceModules"
mkdir "VsHub.dummy\dummy"
)
IF EXIST "VsHub\dummy" (
echo ENABLING VsHub
echo.
rmdir VsHub
mklink /d VsHub VsHub.original
) ELSE (
echo DISABLING VsHub
echo.
rmdir VsHub
mklink /d VsHub VsHub.dummy
)
echo.
pause
On my machine VSHub and its cronies usually use:
This frees up over a 1 GB of RAM with hardly any functionality lost.
I am using Windows 7 x64 with Visual Studio Express 2015. I have terminated annoying processes with Task Manager. Then I have deleted the C:\Program Files (x86)\Common Files\microsoft shared\VsHub folder. This operation solves the problem, but requires administrator rights.
"VsHub" should be renamed to "SmartMobileCloud"; that's how stupidTrendy it is. I dumped it; my VisualC editing/debugging wasn't harmed.
After installing VisualStudio, remove unUsed extensions, do the "C:\Program Files (x86)\Common Files\Microsoft Shared\ - Deleted - VsHub" fix... and put a "VsHub" text file there ( no ".TXT" ), so nothing can recreate the folder.
I thought I’d try to shed some light on the VS Hub and what it’s intended for. I work for Microsoft.
As sraboy mentions, the VS Hub is an out-of-proc services host that Visual Studio (and other VS shell-based products such as Blend) use in order to support multi-tool communication, better responsiveness within devenv (VS), and enable certain services to extend past the lifetime of the spawning process. The set of services currently hosted in the VS Hub includes many of the items called out in the other answers, such as roaming settings, processing of large swaths of ETL data that is rendered in the diagnostics tooling, some telemetry reporting, and extension auto update and notifications. That set of services is very likely to grow in the future though, so even if none of those services seem necessary at the moment, additional services will be hosted there in the future (i.e. it’s a pretty big hammer to disable the vshub.exe through the renaming recommendation :-).
In terms of lifetime, the vshub and host processes (i.e. Microsoft.VsHub.Server.HttpHost(64).exe) can stay running after devenv.exe closes. However, they should not keep running indefinitely. In most cases these processes will terminate within ~5 minutes of the last instance of a VS-based shell closing. So if you have an instance of VS running (devenv.exe) and an instance of Blend running (blend.exe), and you shut down devenv.exe, vshub and the associated host processes will keep running. If you then shut down blend.exe, vshub and the associated host process will still be running. After about 5 minutes from then, however, those additional processes will shut down. If you start another instance of devenv.exe within that 5 minute window, then vshub and the associated host processes will not terminate, and will keep running (basically the host processes terminate whenever they don’t receive any requests within 5 minutes, and after all of the host processes terminate, the vshub.exe process itself terminates).
Resource-wise, the vshub.exe process itself should always be relatively lithe. If it ever gets large, then that’s a bug and I’d love to know about it so we can fix it :-) The host processes, on the other hand, may get very large depending on the service that is being hosted. In particular, the diagnostics tooling works by processing ETL. ETL can be very, very, large, and as such, the host may use a lot of resources. The diagnostics team is looking at ways to reduce that, but for the moment, closing the diagnostics tool window when you don’t need it should help mitigate the problem.
In terms of online connectivity, there are three main sources in the current set of hosted services at the moment (note, this will change over time). First, as user3345048 mentions, the service that detects and auto-updates extensions runs in that process. The options that control that communication are in Tools | Options | Environment | Extensions and Updates (see the first two checkboxes). Second, roaming settings runs as a service in the VS Hub. The setting that controls this behavior is in Tools | Options | Environment | Synchronized settings (or more holistically, if you do not sign into the personalization account in the upper right hand corner of VS). Finally, the VS Hub does report telemetry. The volume of this data can be significantly reduced via the Help | Customer Feedback Options | Settings… menu item. You can also read about the kind of telemetry that Microsoft collects and how it’s used in that location.