visual studio 2015 vshub est le fiddler du spamming

J’ai lu: Comment désactiver VsHub.exe dans la barre d’état système? et https://connect.microsoft.com/VisualStudio/feedback/details/1919828/hundreds-of-calls-second-to-vshub-and-browserlink-is-off

Je préférerais ne pas désactiver vshub; Je veux juste que ce soit plus calme quand j’utilise le violoneux. En ce moment, tout est spams et je ne peux pas faire de débogage général.

Est-ce que quelqu’un connaît une solution de contournement? Puis-je empêcher vshub de apparaître dans le violon sans bloquer le rest de locahost?

Il s’agit d’un problème relativement nouveau car System.NET ignorait les parameters de proxy pour localhost et, par conséquent, Fiddler ne voyait pas le trafic par défaut ( http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp ) – voir la partie inférieure.

Maintenant, cela ne semble plus être le cas, alors je pense que plus de gens auront la même question. Fiddler prend en charge plusieurs façons de filtrer les requêtes, mais rien de ce que le client ne peut contrôler (ce qui est probablement une bonne chose puisque vous ne voudriez pas que le malware exclue son trafic). Le mécanisme le plus approprié et le plus simple dans ce cas est probablement de définir un filtre pour toute URL contenant localhost ou vshub. Vous pouvez le faire en:

  1. Cliquez sur l’onglet filtres (il s’agit d’un onglet de niveau supérieur, au même niveau que les inspecteurs, les statistiques, etc.).
  2. Cochez la case intitulée «Utiliser les filtres»
  3. Faites défiler et recherchez la case à cocher intitulée «Masquer si l’URL contient».
  4. Cochez cette case et entrez localhost ou vshub dans la zone de texte associée.
  5. Vous devriez voir l’arrêt du trafic vshub immédiatement.

Ce filtre persistera, donc si vous fermez Fiddler et le redémarrez plus tard, il sera toujours défini.

Ces requêtes semblent provenir de la fenêtre Outils de diagnostic qui s’exécute lors du débogage. Il semblerait qu’ils fournissent les informations de surveillance pour l’utilisation de la mémoire et l’utilisation du processeur.

Vous pouvez arrêter les demandes si vous ne souhaitez pas voir les informations d’utilisation en désactivant la surveillance de la mémoire / du processeur dans la boîte de dialog Outils de diagnostic.

  • Ouvrez la fenêtre Outils de diagnostic (Debug -> Windows -> Afficher les outils de diagnostic)
  • Cliquez sur le bouton “Sélectionner les outils” et décochez la case Utilisation de la mémoire et utilisation du processeur.
  • Arrêtez le débogage et la prochaine fois que vous commencerez à déboguer, vous ne devriez plus voir les demandes envoyées à vshub

Pour moi, la solution pour arrêter le “spamming” à Fiddler4, au lieu d’un filtre Fiddler, que j’aurais pu choisir, consistait à modifier une option de Visual Studio 2015:

Visual Studio 2015 -> Outils -> Options -> Débogage -> Général -> décocher / désactiver “Activer les outils de diagnostic lors du débogage”

entrer la description de l'image ici

Le service VSHUB.exe doit être le service qui assiste les outils de diagnostic lors du débogage et qui envoie en permanence une requête ping à votre site Web / application Webapi / Web que vous déboguez. Je n’ai pas besoin de débogage. Outils de diagnostic en ce moment, donc je l’ai juste désactivé dans Visual Studio

En ce qui concerne la désactivation de VSHUB.exe, j’ai été tenté de le faire, jusqu’à ce que je lise quelqu’un de Microsoft, de ne pas le désactiver pour améliorer Visual Studio 2015 et d’append de nouvelles fonctionnalités à Visual Studio utilisant VSHUB.exe. temps:

Comment désactiver VsHub.exe dans la barre d’état système?

Le problème est dû aux outils de diagnostic de Visual Studio lors du débogage.

Vous pouvez les désactiver en allant dans OutilsOptions , puis en suivant les étapes: entrer la description de l'image ici

C’est une alternative plus simple pour masquer le trafic vshub.

Accédez à Outils> Options du violon> onglet Connexions et ajoutez http://localhost:49155 à la liste de contournement. Cela ignorera tout le trafic publié sur cette URL.

* Edit: Fiddler peut avoir besoin d’être redémarré après l’ajout à la liste de contournement.

Le moyen le plus simple de résoudre ce problème consiste à configurer un filtre dans Fiddler. Dans le OnBeforeResponse, ajoutez le deuxième si avec votre hôte / port vshub:

  static function OnBeforeResponse(oSession: Session) { if (m_Hide304s && oSession.responseCode == 304) { oSession["ui-hide"] = "true"; } if (oSession.HostnameIs("localhost:49155")){ oSession["ui-hide"] = "hiding vshub"; // Ssortingng value not important } } 

La réponse de SpokaneDJ m’a été très utile et a très bien fonctionné, mais je ne passe pas beaucoup de temps avec Fiddler, alors il m’a fallu une minute pour me rappeler comment faire! Voici les instructions spécifiques.


Tout d’abord, dans l’interface utilisateur du violoniste, accédez à Rules > Customize Rules . Recherchez la fonction OnBeforeResponse . Ça devrait ressembler à ça:

 static function OnBeforeResponse(oSession: Session) { if (m_Hide304s && oSession.responseCode == 304) { oSession["ui-hide"] = "true"; } } 

Ajoutez maintenant le bloc if suivant après celui existant (en remplaçant votre hôte / port vshub si différent):

  if (oSession.HostnameIs("localhost:49155")){ oSession["ui-hide"] = "hiding vshub"; // Ssortingng value not important } 

Votre fonction OnBeforeResponse devrait maintenant ressembler à ceci:

  static function OnBeforeResponse(oSession: Session) { if (m_Hide304s && oSession.responseCode == 304) { oSession["ui-hide"] = "true"; } if (oSession.HostnameIs("localhost:49155")){ oSession["ui-hide"] = "hiding vshub"; // Ssortingng value not important } } 

Ce qui précède n’a pas fonctionné pour moi, en tant que tel. Il a semblé arrêter TOUTES les surveillances de violeurs de l’hôte localhost.

Un peu de googler judicieux m’a donné une autre solution: bloquer le port spécifiquement en l’ajoutant au bas de la section OnBeforeRequest:

 if (oSession.host=="localhost:49155"){ oSession["ui-hide"] = "true"; } 

Cela semble empêcher le port d’être signalé dans Fiddler, sans perturber davantage le trafic localhost.