Wykrywanie proxy .NET

Question

Mam problem z .NET wykrywanie ustawień proxy skonfigurowanych za pomocą przeglądarki Internet Explorer.

Piszę aplikację kliencką obsługującą serwery proxy, a do testowania ustawiam tablicę 9 serwerów kałamarnic, aby obsługiwać różne metody uwierzytelniania dla HTTP i HTTP. Mam skrypt, który aktualizuje IE do dowolnej konfiguracji, którą wybiorę (która to proxy, wykrywanie za pomocą "Auto", PAC lub hardcode).

Próbowałem 3 metody poniżej, aby wykryć konfigurację IE przez .NET. Zdaję się zauważyć, że .NET podnosi niewłaściwy zestaw serwerów proxy. IE ma poprawne ustawienia, a jeśli przeglądam sieć za pomocą IE, widzę, że trafiam na odpowiednie serwery za pomocą wireshark.

WebRequest.GetSystemWebProxy().GetProxy(destination);

GlobalProxySelection.Select.GetProxy(destination);

WebRequest.DefaultWebProxy

Oto następujące wskazówki mam:

• Mój skrypt ustawia plik PAC na serwer i aktualizuje konfigurację w IE, następnie czyści pamięć podręczną IE
• .NET wydaje się "utknąć" na określonej konfiguracji proxy i muszę ustawić inną konfigurację dla .NET, aby zdać sobie sprawę, że nastąpiła zmiana. Od czasu do czasu wydaje się, że wybiera jakiś losowy zbiór serwerów (jestem pewien, że nie są przypadkowe, to tylko zestaw serwerów, które kiedyś użyłem i są w jakimś zbuforowanym pliku PAC lub coś takiego). Jak w, sprawdzę proxy dla miejsca docelowego "https://www.secure.com" i mogę mieć skonfigurowany IE, a więc spodziewać się "http: // squidserver: 18", a zamiast tego zwróci "http : // squidserver: 28 "(port 18 uruchamia NTLM, 28 działa bez uwierzytelnienia). Wszystkie serwery kałamarnic działają.
• To nie wydaje się być problemem tylko na XP, Vista, 2003 i Windows 7.
• hardcoding serwery proxy w IE zawsze działa
• Czas zawsze rozwiązuje problem - jeśli mogę zostawić komputer na około 20 lub 30 minut i wrócą .NET podnosi poprawne ustawienia proxy, tak jakby wygasł buforowany skrypt PAC.

Answer 1

znalazłem rozwiązanie.

.NET używa "usługi automatycznego wykrywania serwera proxy WinHttp" do wykonywania skryptów PAC i prawdopodobnie buforuje wyniki. Po prostu zatrzymanie i ponowne uruchomienie tej usługi rozwiązuje problem. Następująca linia komend wykonuje to za mnie.

NET STOP WinHttpAutoProxySvc 
NET START WinHttpAutoProxySvc 

http://wiki.blackviper.com/wiki/WinHTTP_Web_Proxy_Auto-Discovery_Service

Znalazłem to przez następujące sugestie Jamesa Kovacs' dołączenia debugera. Przeanalizowałem już kod i nieudaną próbę dołączenia debuggera, zanim jeszcze opublikowałem to pytanie, ale nie mogłem dokładnie odczytać, co się dzieje. Ucieka od opcji, próbowałem ponownie debugowania, a po kilku godzinach znaleźć następujący komentarz w _AutoPWebProxyScriptEngine.cs na linii 76, która doprowadziła mnie do tego odkrycia

 // In Win2003 winhttp added a Windows Service handling the auto-proxy discovery. In XP using winhttp 
     // APIs will load, compile and execute the wpad file in-process. This will also load COM, since 
     // WinHttp requires COM to compile the file. For these reasons, we don't use WinHttp on XP, but 
     // only on newer OS versions where the "WinHTTP Web Proxy Auto-Discovery Service" exists. 

Answer 2

miałem ten sam problem i ja succeded pobierania/ustawiania ustawienia proxy w rejestrze:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings] 
"ProxyServer"="<your proxy IP address>:8080" 
"ProxyEnable"=dword:00000001 
"ProxyOverride"="<local>"