Visual Studio 2015 vshub spamuje skrzypce

201

Przeczytałem: Jak wyłączyć VsHub.exe w zasobniku systemowym? i https://connect.microsoft.com/VisualStudio/feedback/details/1919828/hundreds-of-calls-second-to-vshub-and-browserlink-is-off

Wolałbym nie wyłączać vshub; Chcę tylko, żeby było ciszej, kiedy korzystam ze skrzypka. W tej chwili wyrzuca wszystko inne i nie mogę przeprowadzić ogólnego debugowania.

Czy ktoś zna obejście? Czy mogę zablokować wyświetlanie vshub w skrzypcach bez blokowania reszty locahost?

Greg Netland
źródło

Odpowiedzi:

268

Jest to stosunkowo nowy problem, ponieważ System.NET ignorował ustawienia proxy dla localhost, a zatem Fiddler domyślnie nie widział ruchu ( http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp ) - patrz dolna część.

Teraz już tak nie jest, więc spodziewam się, że więcej osób będzie miało to samo pytanie. Fiddler obsługuje kilka sposobów filtrowania żądań, chociaż nic nie jest w stanie kontrolować klient (co prawdopodobnie jest dobre, ponieważ nie chcesz, aby złośliwe oprogramowanie wykluczało jego ruch). Najodpowiedniejszym i najprostszym mechanizmem w tym przypadku jest prawdopodobnie ustawienie filtra dla dowolnego adresu URL zawierającego localhost lub vshub. Możesz to zrobić przez:

  1. Kliknij kartę filtrów (jest to karta najwyższego poziomu, na tym samym poziomie, co inspektorzy, statystyki itp.),
  2. Zaznacz pole wyboru oznaczone „Użyj filtrów”
  3. Przewiń w dół i znajdź pole wyboru „Ukryj, jeśli URL zawiera”.
  4. Zaznacz to pole i wpisz localhost lub vshub w towarzyszącym polu tekstowym.
  5. Powinieneś natychmiast zobaczyć zatrzymanie ruchu vshub.

Ten filtr będzie się utrzymywał, więc jeśli zamkniesz Fiddlera i uruchomisz go później, nadal będzie ustawiony.

Anson Horton
źródło
4
Dzięki, @Anson. Ukrywanie tak dużej liczby żądań sprawi, że Fiddler będzie znów użyteczny. Ale nadal pozostaje to poważnym problemem. To sprawia, że ​​zastanawiasz się, dlaczego Visual Studio lub jakikolwiek późniejszy związany z nim proces wysyła te żądania w pierwszej kolejności (retoryczne). Jeśli to ci też nie przeszkadza, dodaj głos w sprawie błędu MS Connect # 1919828 i / lub poprzez problem ASP.NET MVC # 3655 .
Juliën,
4
Aby dodać, możesz użyć || operator w polu „Ukryj, jeśli URL zawiera”, jeśli chcesz ukryć inne żądania, takie jak link do przeglądarki.
Nick Spicer
4
@ Moriarty re: ...why Visual Studio is making these requests... cóż, dzieje się tak, ponieważ procesy komunikują się ze sobą za pośrednictwem protokołu HTTP na adapterze pętli zwrotnej. . Ten ruch został wygenerowany „przez chwilę” teraz; niedawno zmieniono to, że jest domyślnie widoczne dla serwerów proxy HTTP ... więc nie jestem pewien, dlaczego uważasz to za błąd.
K. Alan Bates
2
Co jest efektem ubocznym nowych narzędzi do zdalnego debugowania w Visual Studio 2015, jestem całkiem pewien. Zwłaszcza w związku z debugowaniem międzyplatformowym dla Cordova na urządzeniach Apple. Prawdopodobnie zbudowali te zmiany w taki sposób, że mogą później rozszerzyć je na inne platformy, stąd globalna zmiana.
Bon
1
To nie jest właściwe rozwiązanie. Po prostu ukrywa problem. Rozwiązania poniżej usuwania narzędzi diagnostycznych podczas debugowania w VS to prawdziwe rozwiązanie.
Rafi,
132

Te żądania wydają się pochodzić z okna narzędzi diagnostycznych, które jest uruchamiane podczas debugowania. Wydaje się, że dostarczają one informacji o monitorowaniu zużycia pamięci i wykorzystania procesora.

Możesz zatrzymać żądania, jeśli nie chcesz zobaczyć informacji o użyciu, wyłączając monitorowanie pamięci / procesora w oknie dialogowym Narzędzia diagnostyczne.

  • Otwórz okno Narzędzia diagnostyczne (Debugowanie -> Windows -> Pokaż narzędzia diagnostyczne)
  • Kliknij menu „Wybierz narzędzia” i usuń zaznaczenie opcji Zużycie pamięci i Zużycie procesora.
  • Zatrzymaj debugowanie i następnym razem, gdy rozpoczniesz debugowanie, nie będziesz już widzieć żądań wysyłanych do vshub
Alex
źródło
10
To prawidłowe rozwiązanie. Natychmiast pozbył się wszystkich spamujących wiadomości. W tej chwili nie dbam o procesor / pamięć, potrzebuję skrzypka, aby pozostać czysty, aby móc go prawidłowo używać. Tak wielkie Dzięki Tobie Alex za tę poprawkę.
Pic Mickael,
6
Pomoże to tylko raz, ale możesz wyłączyć „Narzędzia diagnostyczne” w Vusial Studio tutaj: Narzędzia -> Opcje -> Debugowanie -> Ogólne -> pole wyboru „Włącz narzędzia diagnostyczne podczas debugowania”
Andrey Prokhorov
1
Nie mogę znaleźć menu rozwijanego „Wybierz narzędzia” (w Visual Studio 2015). Wiesz, gdzie to jest?
Per Lundberg
1
@PerLundberg Jeśli nie możesz znaleźć „Wybierz narzędzia”, spróbuj odpowiedzi Briana poniżej (tak samo jak Andrey w tych komentarzach). To jest teraz moje preferowane rozwiązanie polegające na wyłączeniu monitorowania pamięci / procesora przez cały czas. Jeśli go potrzebuję, wiem, jak go włączyć.
Alex
Zauważ, że jeśli jesteś w sesji debugowania i robisz opcję Alexa, a monitorowanie pamięci / procesora zostanie zatrzymane, żądania nie zostaną zatrzymane, dopóki nie zatrzymasz i nie uruchomisz ponownie sesji debugowania! Odkryłem to na własnej skórze.
vapcguy
88

Dla mnie poprawką, aby zatrzymać „spamowanie” Fiddler4, zamiast filtru Fiddler, co mogłem wybrać, była zmiana opcji Visual Studio 2015:

Visual Studio 2015 -> Narzędzia -> Opcje -> Debugowanie -> Ogólne -> odznacz / wyłącz „Włącz narzędzia diagnostyczne podczas debugowania”

wprowadź opis zdjęcia tutaj

Usługa VSHUB.exe musi być usługą, która pomaga narzędziom diagnostycznym podczas debugowania i stale pinguje twoją stronę / webapi / aplikację sieciową, którą debugujesz. Nie potrzebuję debugowania. Narzędzia diagnostyczne w tej chwili, więc właśnie wyłączyłem je w Visual Studio

Jeśli chodzi o wyłączenie VSHUB.exe, miałem ochotę to zrobić, dopóki nie przeczytałem od kogoś w firmie Microsoft, najlepiej nie wyłączać go, aby uzyskać lepszą obsługę programu Visual Studio 2015 i dodają nowe funkcje do programu Visual Studio korzystającego z VSHUB.exe czas:

Jak wyłączyć VsHub.exe w zasobniku systemowym?

Brian Ogden
źródło
@BrianOgden Phew! Dziękuję Ci. Wreszcie odpowiedź VS 2015. Menu Visual Studio bardzo się zmieniło w poszczególnych wydaniach. Nagle to narzędzie - VsHub - zrobiło się dziwne i nie wiem dlaczego. Dzięki automatycznym aktualizacjom systemu Windows 10 mogło to być bez mojej wiedzy.
octopusgrabbus
Uwaga dla każdego, kto robi to w ten sposób, jeśli zrobisz to w trakcie sesji debugowania, twoje żądania nie przestaną być przechwytywane w Fiddler, dopóki nie zatrzymasz i nie uruchomisz ponownie sesji debugowania.
vapcguy
21

Przyczyną tego problemu są narzędzia diagnostyczne programu Visual Studio podczas debugowania.

Możesz je wyłączyć, przechodząc do NarzędziaOpcje , a następnie wykonując następujące czynności: wprowadź opis zdjęcia tutaj

Siergiej
źródło
Ładna grafika. Brian Ogden już cię do tego pobił - duplikat odpowiedzi. Uwaga dla każdego, kto robi to w ten sposób, jeśli zrobisz to w trakcie sesji debugowania, twoje żądania nie przestaną być przechwytywane w Fiddler, dopóki nie zatrzymasz i nie uruchomisz ponownie sesji debugowania.
vapcguy
@vapcguy Muszę przyznać, że moja odpowiedź nie jest inna , ale był pierwszym, aby umieścić grafikę. Brian zredagował później swoją odpowiedź, dołączając grafikę. Wszystko jest w porządku, dopóki ludzie otrzymują odpowiedzi.
Sergey,
20

Jest to łatwiejsza alternatywa do ukrycia ruchu vshub.

Przejdź do Narzędzia> Opcje Fiddler> zakładka Połączenia i dodaj http://localhost:49155do listy obejść. Spowoduje to pominięcie całego ruchu opublikowanego pod tym adresem URL.

* Edycja: Fiddler może wymagać ponownego uruchomienia po dodaniu do listy obejść.

mikro
źródło
2
Ta zmiana została zastosowana dopiero po ponownym uruchomieniu Fiddler.
Bassem,
@Bassem, to również bez ponownego uruchamiania dla mojego.
Smit Patel,
9

Najłatwiejszym sposobem rozwiązania tego problemu jest skonfigurowanie filtra w skrzypaczu. W OnBeforeResponse dodaj drugą, jeśli z twoim hostem / portem 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"; // String value not important
    }


    }
SpokaneDJ
źródło
2

Odpowiedź SpokaneDJ była dla mnie bardzo pomocna i działała świetnie, ale nie spędzam dużo czasu z Fiddlerem, więc zapamiętanie jak to zrobić zajęło mi minutę! Oto szczegółowe instrukcje.


Najpierw w interfejsie Fiddler przejdź do Rules> Customize Rules. Wyszukaj OnBeforeResponsefunkcję. To powinno wyglądać tak:

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

Teraz dodaj następujący if blok po istniejącym (zastępując host / port vshub, jeśli jest inny):

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

Twoja OnBeforeResponsefunkcja powinna teraz wyglądać następująco:

  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"; // String value not important
    }
  }
Brian Lacy
źródło
0

Powyższe nie działało dla mnie jako takie. Wydawało się, że zamyka WSZYSTKIE monitorowanie skrzypcowego hosta localhost.

Trochę rozsądnego googlinga dało mi inne rozwiązanie - konkretnie zablokować port, dodając to na dole sekcji OnBeforeRequest:

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

To wydaje się blokować raportowanie portu w Fiddler, bez zakłócania dalszego ruchu localhost.

Rich Howard
źródło
1
Powinieneś wspomnieć, którą odpowiedź nazywasz „powyższą”, ponieważ odpowiedzi tutaj mogą się zmieniać w zależności od wielu czynników.
Sergey
Uczciwy punkt. W tym czasie miał zastosowanie do wszystkich innych rozwiązań, ale wydaje się, że od tego czasu dodano więcej. Będę o tym pamiętać w przyszłości.
Rich Howard,