Ho un servizio WCF che accetta un tipo complesso e restituisce alcuni dati. Voglio usare Fiddler per vedere come sono le richieste in arrivo al servizio. Il client è l'app console .net che utilizza un proxy di riferimento del servizio. È possibile con Fiddler. Sono nuovo in questo strumento e l'ho usato solo in passato per pubblicare i dati con il builder della richiesta.Come utilizzare Fiddler per monitorare il servizio WCF
Fiddler ascolta le richieste in uscita anziché le richieste in entrata in modo da non essere in grado di monitorare tutte le richieste che arrivano al tuo servizio utilizzando Fiddler.
Il meglio che si ottiene con Fiddler è la possibilità di vedere tutte le richieste generate dall'app Console (presupponendo che l'app generi richieste Web anziché utilizzare altre pipeline).
Se si desidera uno strumento più potente (ma più difficile da utilizzare) che consenta di monitorare TUTTE le richieste in entrata, è necessario verificare WireShark.
Modifica
mi correggo. Grazie a Eric Law per aver pubblicato le indicazioni per configuring Fiddler to be a reverse proxy!
Grazie per le informazioni. Ho bisogno di visualizzare la struttura della richiesta simile alla pagina di descrizione per i servizi asmx. WCF non sembra avere questa opzione. – Quadwwchs
Questo non è abbastanza preciso (e "potere" è soggettivo, poiché WireShark non può cambiare il traffico). Vedi http://www.fiddler2.com/fiddler/help/reverseproxy.asp per maggiori dettagli su come ascoltare il traffico in entrata. – EricLaw
Eric - Suggerisco di affermarlo in una risposta autonoma. – Cheeso
Questo è semplice se si ha il controllo sul client che sta inviando le comunicazioni. Tutto ciò che devi fare è impostare HttpProxy sulla classe di servizio lato client.
Ho fatto questo, ad esempio, per rintracciare un client di servizi Web in esecuzione su uno smartphone. Ho impostato il proxy su quella connessione lato client all'IP/port di Fiddler, che era in esecuzione su un PC sulla rete. L'app per smartphone ha quindi inviato tutte le comunicazioni in uscita al servizio web, tramite Fiddler.
Questo ha funzionato perfettamente.
Se il client è un client WCF, vedere this Q&A per come impostare il proxy.
Anche se non si ha la possibilità di modificare il codice dell'app lato client, è possibile impostare il proxy in modo amministrativo, a seconda dello stack dei servizi Web utilizzato dal client.
È necessario aggiungere questo nel tuo web.config
<system.net>
<defaultProxy>
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
</system.net>
Questo è tutto, ma non dimenticare di rimuovere le righe di web.config dopo aver chiuso il violinista, perché se non lo facesse si commetterebbe un errore.
Riferimento: http://fiddler2.com/documentation/Configure-Fiddler/Tasks/UseFiddlerAsReverseProxy
Questo ha funzionato alla grande per me - grazie! –
Grazie, mi ha davvero aiutato. Il mio errore non era quello di specificare 'http: //' nell'indirizzo proxy. Tutto il resto era lo stesso, come hai detto. –
Questo non ha funzionato per me. La mia situazione è: il server è IIS7.5, il client è un'applicazione console. Nella mia app console, ho chiamato un metodo WebService che è distribuito su IIS7.5 sul mio computer di sviluppo.Replacing "localhost" con il mio nome computer ha funzionato per me. – york
ho usato strumento di squalo fili per le chiamate di servizio di monitoraggio da luce argentea App nel browser per il servizio. prova il link fornisce informazioni chiare
Consente di monitorare l'intera richiesta e il contenuto della risposta.
Così semplice, tutto ciò che serve è cambiare l'indirizzo nel client config: invece di cambiare 'localhost' per il nome del computer o IP
Proprio avuto questo problema, che cosa ha funzionato per me è stato quello di utilizzare localhost. fiddler:
<endpoint address="http://localhost.fiddler/test/test.svc"
binding="basicHttpBinding"
bindingConfiguration="customBinding"
contract="test"
name="customBinding"/>
è necessario assicurarsi che il fiddler sia avviato affinché funzioni. – Shekhar
Consolidare le avvertenze citate nei commenti/risposte per diversi casi d'uso.
Per lo più, vedi http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp
In una console app, potrebbe non essere necessario specificare il proxyaddress:
<proxy bypassonlocal="False" usesystemdefault="True" />
in un'applicazione web/qualcosa ospitato in IIS, è necessario aggiungere il proxyaddress:
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
HttpWebRequest, ecc.), Ignorerà sempre il proxy Fiddler per gli URL che contengono localhost, quindi è necessario utilizzare un alias come il nome del computer o creare qualcosa nel tuo ' file hosts' (che è il motivo per cui qualcosa come localhost.fiddler o http://HOSTNAME opere)se si specifica il proxyaddress, è necessario rimuoverlo dalla propria configurazione se Fiddler è spento, o eventuali richieste tue marche app un'eccezione come:
Nessuna connessione può essere effettuata perché la macchina di destinazione ac tivamente rifiutò 127.0.0.1:8888
I servizi WCF tracing sono abbastanza buone da soli tra cui una bella interfaccia grafica per la loro visualizzazione. http://msdn.microsoft.com/en-us/library/ms751526.aspx – kenny