Limitazioni del debug di WCF
Aggiornamento: novembre 2007
Le informazioni contenute in questo argomento sono valide per:
Edition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif) |
|
|
|
Standard |
.gif) |
|
|
|
Pro e Team |
|
|
|
|
Legenda tabella:
|
Applicabile |
|
Non applicabile |
.gif) |
Comando o comandi nascosti per impostazione predefinita. |
Sono disponibili tre modalità per avviare il debug di un servizio WCF:
Si supponga di eseguire il debug di un processo client che chiama un servizio. Il debugger esegue il servizio. Il servizio non deve essere presente nella stessa soluzione dell'applicazione client.
Si supponga di eseguire il debug di un processo client che effettua una richiesta a un servizio. Il servizio deve essere parte della soluzione.
Si supponga di utilizzare Connetti a processo per la connessione a un servizio correntemente in esecuzione. Ha inizio il debug del servizio.
In questo argomento vengono descritte le limitazioni di questi scenari.
Limitazioni dell'esecuzione di un servizio
Per eseguire istruzioni in un servizio da applicazioni client delle quali si sta eseguendo il debug, è necessario soddisfare le condizioni seguenti:
Il client deve chiamare il servizio utilizzando un oggetto client sincrono.
L'operazione del contratto non può essere unidirezionale.
Se il server è asincrono, non è possibile visualizzare lo stack di chiamate completo durante l'esecuzione del codice nel servizio.
Il debug deve essere attivato con il codice riportato di seguito nel file app.config o web.config:
<system.web> <compilation debug="true" /> <system.web>Questo codice deve essere aggiunto solo una volta. È possibile aggiungere questo codice modificando il file con estensione config o attraverso la connessione al servizio utilizzando Connetti a processo. Quando si utilizza Connetti a processo in un servizio, il codice di debug viene aggiunto automaticamente al file config. Successivamente, è possibile eseguire il debug e le istruzioni nel servizio senza dovere modificare il file config.
Limitazioni dell'uscita da un servizio
L'uscita da un servizio e il ritorno al client presenta le stesse limitazioni descritte per l'esecuzione di un servizio. Inoltre, il debugger deve essere connesso al client. Se è in corso il debug di un client e l'esecuzione di istruzioni in un servizio, il debugger rimane connesso al servizio. Questo è vero se il client è stato avviato utilizzando Avvia debug o ci si è connessi al client utilizzando Connetti a processo. Se si avvia il debug attraverso la connessione al servizio, il debugger non è ancora connesso al client. In quel caso, se è necessario uscire del servizio e tornare al client, prima è necessario utilizzare Connetti a processo per la connessione manuale al client.
Limitazioni della connessione automatica a un servizio
La connessione automatica a un servizio presenta le limitazioni riportate di seguito:
Il servizio deve essere parte della soluzione Visual Studio della quale si sta eseguendo il debug.
Il servizio deve essere ospitato. Può essere parte di un progetto di sito Web (File system e HTTP), un progetto di applicazione Web (File system e HTTP) o un progetto libreria servizio WCF. I progetti libreria servizio WCF possono essere librerie di servizio o librerie di servizi di flusso.
Il servizio deve essere richiamato da un client WCF.
Il debug deve essere attivato con il codice riportato di seguito nel file app.config o web.config:
<system.web> <compilation debug="true" /> <system.web>
Indipendenza dei servizi
Un servizio indipendente è un servizio WCF che non è in esecuzione in IIS, nell'host servizio WCF o sul server di sviluppo ASP.NET. Per informazioni su come eseguire il debug di un servizio indipendente, vedere Procedura: eseguire il debug di un servizio WCF indipendente.
Vedere anche
Attività
Procedura: eseguire il debug di un servizio WCF indipendente