How can I disable Task Runner Explorer in Visual Studio?

Question

The Task Runner Explorer just throws errors for me in Visual Studio 2015 RC and I just want to disable it and run my gulp file from the command line like I always have. Is there a way to turn off the Task Runner Explorer?

Answer 1

Open the Task Runner pane and disable all "On Build" actions.

Answer 2

I've been having problems with Visual Studio 2015 spinning up a gazillion instance of node.exe, over and over and over again whenever I open our web site solution. That caused the McAfee nannyware and the Dell encryption software they've installed on our dev boxes to go nuts.

Between it all, it was pretty much consuming the entire CPU. Needless to say, this made it...difficult...to get things done.

So, I got to thinking about things, and I figured that if I could stub out the node, npm and gulp binaries, they at least wouldn't be able to consum any CPU. So, I wrote about the simplest stub console apps imaginable. My own versions of

• node.exe
• gulp.exe
• npm.exe
• and an npm.cmd that simply ran my npm.exe, passing its command line arguments long.

The only thing each of these executables do is to use log4net and write a line to a log file, with the name of the executable and listing the arguments the executable was invoked with. I parked the 4 of these in a directory by themselves and used the post Synchronize Node.JS Install Version with Visual Studio to configure Visual Studio 2015 to put my stubbed executables at the top of the search path.

WELL ...

It works out that Visual Studio 2015 was repeatedly invoking npm like this:

npm ls -g

So I went to the root of our project and ran that same command (using the real binaries). Lo and behold, npm was hurling and reporting errors, trying to open a non-existent package.json located in the tree rooted at

C:\Users\{user-id}\AppData\Roaming\npm\node_modules

It looked to be cruft leftover from some time back that had left empty directories out there. Once I removed the empty directories where it was trying to open a non-existent package.json, life is good.

NOTE: Somebody requested the stub executables I describe here via a comment. You can find the source code for them in Github at https://github.com/nbcarey/vs2015-node-stubs/

Enjoy.

Answer 3

In Visual Studio 2015 you can prevent Gulp from running on every build.

• Open the Task Runner Explorer
• Click on the Bindings tab (shown below)
• Select any entries in the tree and press Delete

When that is done, the bindings tree should look as shown with zeroes after each top level item.

---

Note that making the above changes via the UI ultimately removes items from the gulpfile.js itself, so you can just as easily make this change by removing anything resembling:

/// <binding AfterBuild='default' />
/// <binding Clean='clean' />

Answer 4

This isn't "in Visual Studio", but you can open up your gulpfile.js and delete the generated line at the top of the file. You might also need to reload your solution afterward, I'm not sure.

I came here looking for an answer as well and just noticed that there was a new line in my gulpfile.js. I looked for when this started and it turns out that when I upgraded my Azure SDK to 2.7 and started using Visual Studio 2015 RTM, it injected this line in my gulpfile.

If someone does find a way to do this through Visual Studio rather than hacking out generated lines in a file, I'd also like to know.

Answer 5

The links at the bottom explain how to disable packages (extensions) that are built into Visual Studio.

Basically:

• Navigate to C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools.
• Backup the extension.vsixmanifest file and the TaskRunnerExplorer directory.
• Look in the TaskRunnerExplorer\*.pkg files and take note of GUID keys at the top of the files (e.g. [$RootKey$\Packages\{b483c4e7-43a6-4f7b-a9a1-79e2c5d12148}]).
• Edit the extension.vsixmanifest file and remove any mention of TaskRunnerExplorer.
• Delete the TaskRunnerExplorer directory.
• Backup and delete the GUID key(s) from the registry, inside of HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0_Config\Packages\. Currently, those keys are {8da206d4-9521-4f38-92c9-a8d5d0af611c} and {b483c4e7-43a6-4f7b-a9a1-79e2c5d12148}.

Note: To edit files in Program Files (x86), you either have to run your notepad app in Admin mode or edit a copy from within a directory that you own and then overwrite the original.

http://blog.spinthemoose.com/2012/12/28/how-to-unregister-a-visual-studio-package-extension/

http://blog.spinthemoose.com/2013/01/02/the-correct-way-to-uninstall-visual-studio-packages-extensions/

Answer 6

After all I was able to solve the problem of disabling any unnecessary Visual Studio package in a clean and minimally invasive way, which does not require changing of VS configuration files or fiddling with the registry! This includes Task Runner facility, VsHub facility which causes a lot of VS instability and slowdown as well as any other VS Package out of 150+ it ships with.

Here is a short recap: Basic functionality component for VS is a Package (don’t mix it up with NuGet packages – those are not relevant here). All extensions you may install from Web (as well as many preinstalled ones) are in the form of VSIX which is extended Package format. Visual Studio has an API (unpublished, but still) which can work with VSIX packages, including finding them and Enable/Disable them. Unfortunately it only can handle VSIX and does not see pure VS Packages. This is declared by design – pure VS Packages are considered system components and do not have supported way to Disable them. Or so they say… I have decompiled official (although badly outdated) MS plugin for extensions diagnostics and found that it does a lot of fiddling directly with the registry to obtain information about installed VSPackages, but does not even try to change anything there (think Disable). My own investigation of HKCU\Software\Microsoft\VisualStudio discovered that huge and elaborate data structure there is useless to fiddle with as it is merely the cache of VS internal state which VS refreshes randomly and often, so even if we figure out how to disable the package through registry it would be pointless as VS would overwrite it right away.

Two clues which finally brought me to the final solution were those: 1. There is a file C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.pkgdef The content of that file is not particularly interesting, but my C++ past gave me a hint that if there is PkgDef, there is a good chance there may be PkgUnDef also, even though it is normally not present. ProcMon confirmed that during startup VS checks for devenv.pkgundef file presence and I was on the right path. 2. Second hint – I know that some other products (think SQL Server Management Studio) use VS Shell in disguise (that’s why you still see VS 2010 in your Add\Remove programs – it is SQL SMS). And those other products obviously have a way to cut out most of VS functionality and only leave a few features they really need from it. So I learned how they do it and here you go – pkgundef file again!

It was a matter of a few probes and registry scans to write the correct content for devenv.PkgUnDef to get rid of the packages I don’t like with no visible side effects or bad consequences.

My C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.pkgundef looks like that:

// Exclude TaskRunnerExplorer
[$RootKey$\Packages\{b483c4e7-43a6-4f7b-a9a1-79e2c5d12148}]
// Exclude VsHubServicePackage
[$RootKey$\Packages\{F419E6BB-F72F-42CF-ACFE-D0D0E17FCB17}]
// Exclude JavaScriptWebExtensionsPackage
[$RootKey$\Packages\{30db8f9b-ec9f-44d6-b377-83c7c27a1a8b}]

To check what specific packages you have loaded there is Extension Analyser. It is rather dated, so I hacked together a version which works with VS 2015 here.

Another way to see what slows VS down is to run it with the /Log parameter and apply Activity Log Proviler.

Hope it helps people to regain their slim and fast Visual Studio! Konstantin