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?

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.


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

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?


@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ędzia ➜ Opcje , a następnie wykonując następujące czynności: wprowadź opis zdjęcia tutaj


Ł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ść.


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
    }


    }

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
    }
  }

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.


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,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.