Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In questo argomento vengono elencati alcuni problemi noti riscontrati dai clienti durante lo sviluppo di client e servizi WCF. Se il problema riscontrato non è incluso in questo elenco, è consigliabile configurare il tracciamento per il tuo servizio. Verrà generato un file di traccia che è possibile visualizzare con il visualizzatore file di traccia e ottenere informazioni dettagliate sulle eccezioni che potrebbero verificarsi all'interno del servizio. Per altre informazioni sulla configurazione della traccia, vedere Configurazione della traccia. Per altre informazioni sul visualizzatore di file di traccia, vedere: Service Trace Viewer Tool (SvcTraceViewer.exe).
-
Errore HTTP 404.3 - Non trovatoLa pagina che si sta richiedendo non può essere servita a causa della configurazione dell'estensione. Se la pagina è uno script, aggiungere un gestore. Se il file deve essere scaricato, aggiungere una mappa MIME. Informazioni dettagliate sull'erroreModule StaticFileModule.
Qual è l'indirizzo di base? In che modo è correlato a un indirizzo endpoint?
Dopo aver installato Windows 7 e IIS, quando si tenta di passare a un servizio WCF viene visualizzato il messaggio di errore seguente: Errore HTTP 404.3 - Non trovato
Il messaggio di errore completo è:
Errore HTTP 404.3 - Non trovatoLa pagina che si sta richiedendo non può essere servita a causa della configurazione dell'estensione. Se la pagina è uno script, aggiungere un gestore. Se il file deve essere scaricato, aggiungere una mappa MIME. Informazioni dettagliate sull'erroreModule StaticFileModule.
Questo messaggio di errore si verifica quando l'attivazione HTTP di Windows Communication Foundation non è impostata in modo esplicito nel Pannello di controllo. Per impostare questa opzione, fare clic su Programmi nell'angolo inferiore sinistro della finestra. Fare clic su Attiva o disattiva funzionalità di Windows. Espandere Microsoft .NET Framework 3.5.1 e selezionare Attivazione HTTP di Windows Communication Foundation.
A volte si riceve un'eccezione MessageSecurityException nella seconda richiesta se il client è inattivo per un po' dopo la prima richiesta. Cosa sta succedendo?
La seconda richiesta può avere esito negativo principalmente per due motivi: (1) il timeout della sessione o (2) il server Web che ospita il servizio viene riciclato. Nel primo caso, la sessione è valida fino al timeout del servizio. Quando il servizio non riceve una richiesta dal client entro il periodo di tempo specificato nell'associazione del servizio (ReceiveTimeout), il servizio termina la sessione di sicurezza. I messaggi del client successivi generano il risultato MessageSecurityException. Il cliente deve ristabilire una sessione sicura con il servizio per inviare messaggi futuri o utilizzare un token di contesto di sicurezza con stato attivo. I token del contesto di sicurezza con stato consentono anche a una sessione sicura di sopravvivere a un server Web riciclato. Per altre informazioni sull'uso di token di contesto sicuri con stato in una sessione sicura, vedere Procedura: Creare un token di contesto di sicurezza per una sessione sicura. In alternativa, è possibile disabilitare sessioni sicure. Quando si usa l'associazione <wsHttpBinding> , è possibile impostare la establishSecurityContext proprietà su false per disabilitare le sessioni protette. Per disabilitare le sessioni sicure per altre associazioni, è necessario creare un'associazione personalizzata. Per informazioni dettagliate sulla creazione di un'associazione personalizzata, vedere Procedura: Creare un'associazione personalizzata tramite SecurityBindingElement. Prima di applicare una di queste opzioni, è necessario comprendere i requisiti di sicurezza dell'applicazione.
Il servizio inizia a rifiutare nuovi client dopo che circa 10 client interagiscono con esso. Cosa sta succedendo?
Per impostazione predefinita, i servizi possono avere solo 10 sessioni simultanee. Pertanto, se le associazioni del servizio usano sessioni, il servizio accetta nuove connessioni client fino a raggiungere tale numero, dopo il quale rifiuta nuove connessioni client fino al termine di una delle sessioni correnti. È possibile supportare più client in diversi modi. Se il servizio non richiede sessioni, non usare un'associazione con sessione. Per altre informazioni, vedere Uso di sessioni. Un'altra opzione consiste nell'aumentare il limite di sessione modificando il valore della MaxConcurrentSessions proprietà sul numero appropriato per le circostanze.
È possibile caricare la configurazione del servizio da un punto diverso dal file di configurazione dell'applicazione WCF?
Sì, tuttavia, è necessario creare una classe personalizzata ServiceHost che esegue l'override del ApplyConfiguration metodo . All'interno di questo metodo, è possibile chiamare prima la base per caricare la configurazione (se si desidera caricare anche le informazioni di configurazione standard), ma è anche possibile sostituire completamente il sistema di caricamento della configurazione. Se si vuole caricare la configurazione da un file di configurazione diverso dal file di configurazione dell'applicazione, è necessario analizzare manualmente il file di configurazione e caricare la configurazione.
Nell'esempio di codice seguente viene illustrato come eseguire l'override del ApplyConfiguration metodo e configurare direttamente un endpoint.
public class MyServiceHost : ServiceHost
{
public MyServiceHost(Type serviceType, params Uri[] baseAddresses)
: base(serviceType, baseAddresses)
{
Console.WriteLine("MyServiceHost Constructor");
}
protected override void ApplyConfiguration()
{
string straddress = GetAddress();
Uri address = new Uri(straddress);
Binding binding = GetBinding();
base.AddServiceEndpoint(typeof(IData), binding, address);
}
string GetAddress()
{
return "http://MyMachine:7777/MyEndpointAddress/";
}
Binding GetBinding()
{
WSHttpBinding binding = new WSHttpBinding();
binding.Security.Mode = SecurityMode.None;
return binding;
}
}
Il mio servizio e il client funzionano benissimo, ma non riesco a farli funzionare quando il client si trova su un altro computer. Cosa sta succedendo?
A seconda dell'eccezione, potrebbero verificarsi diversi problemi:
Potrebbe essere necessario modificare gli indirizzi dell'endpoint client con il nome host e non "localhost".
Potrebbe essere necessario aprire la porta all'applicazione. Per informazioni dettagliate, vedere Istruzioni del firewall degli esempi dell'SDK.
Per altri problemi possibili, vedere l'argomento relativo agli Esempi Running the Windows Communication Foundation Samples.
Se il tuo cliente utilizza le credenziali di Windows e l'eccezione è SecurityNegotiationException, configura Kerberos come segue.
Aggiungere le credenziali di identità all'elemento endpoint nel file di App.config del client:
<endpoint address="http://MyServer:8000/MyService/" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IServiceExample" contract="IServiceExample" behaviorConfiguration="ClientCredBehavior" name="WSHttpBinding_IServiceExample"> <identity> <userPrincipalName value="name@corp.contoso.com"/> </identity> </endpoint>Eseguire il servizio ospitato autonomamente con l'account System o NetworkService. È possibile eseguire questo comando per creare una finestra di comando nell'account di sistema:
at 12:36 /interactive "cmd.exe"Ospita il servizio sotto Internet Information Services (IIS), che, per impostazione predefinita, utilizza l'account del nome principale del servizio (SPN).
Registrare un nuovo SPN con il dominio usando SetSPN. Per eseguire questa operazione, è necessario essere un amministratore di dominio.
Per altre informazioni sul protocollo Kerberos, vedere Concetti di sicurezza usati in WCF e:
Quando lancio un FaultException<Exception> dove il tipo è un'eccezione, ricevo sempre un tipo FaultException generico sul client e non il tipo specifico. Cosa sta succedendo?
È consigliabile creare un tipo di dati di errore personalizzato e dichiararlo come tipo di dettaglio nel contratto di errore. Il motivo è l'utilizzo di tipi di eccezione forniti dal sistema.
Crea una dipendenza di tipo che rimuove una delle principali funzionalità delle applicazioni orientate ai servizi.
Non si può fare affidamento sulla serializzazione delle eccezioni in modo standard. Alcuni, come SecurityException, potrebbero non essere serializzabili affatto.
Espone i dettagli di implementazione interni ai client. Per altre informazioni, vedere Specifica e gestione degli errori nei contratti e nei servizi.
Se si esegue il debug di un'applicazione, tuttavia, è possibile serializzare le informazioni sulle eccezioni e restituirla al client usando la ServiceDebugBehavior classe .
Sembra che le operazioni monodirezionali e richiesta-risposta restituiscano all'incirca lo stesso ritmo quando la risposta non contiene dati. Come mai?
Specificare che un'operazione è unidirezionale significa solo che il contratto dell'operazione accetta un messaggio di input e non restituisce un messaggio di output. In WCF, tutte le chiamate client ritornano quando i dati in uscita sono stati scritti sul filo o viene generata un'eccezione. Le operazioni unidirezionali funzionano allo stesso modo e possono generare un'eccezione se il servizio non può essere individuato o bloccato se il servizio non è pronto ad accettare i dati dalla rete. In genere in WCF, ciò comporta la restituzione di chiamate unidirezionale al client più rapidamente rispetto a request-reply; ma qualsiasi condizione che rallenta l'invio dei dati in uscita sulla rete rallenta le operazioni unidirezionali e le operazioni request-reply. Per altre informazioni, vedere One-Way Services e Accesso ai servizi usando un client WCF.
Sto usando un certificato X.509 con il mio servizio e ottengo un'eccezione System.Security.Cryptography.CryptographicException. Cosa sta succedendo?
Ciò si verifica in genere dopo la modifica dell'account utente in cui viene eseguito il processo di lavoro IIS. Ad esempio, in Windows XP, se si modifica l'account utente predefinito in cui viene eseguito il Aspnet_wp.exe da ASPNET a un account utente personalizzato, è possibile che venga visualizzato questo errore. Se si usa una chiave privata, il processo che lo usa dovrà avere le autorizzazioni per accedere al file che archivia tale chiave.
In questo caso, è necessario concedere privilegi di accesso in lettura all'account del processo per il file contenente la chiave privata. Ad esempio, se il processo di lavoro IIS è in esecuzione con l'account Bob, sarà necessario concedere a Bob l'accesso in lettura al file contenente la chiave privata.
Per altre informazioni su come concedere all'account utente corretto l'accesso al file contenente la chiave privata per un certificato X.509 specifico, vedere Procedura: Rendere accessibili i certificati X.509 a WCF.
Ho modificato il primo parametro di un'operazione da maiuscolo a minuscolo; ora il client genera un'eccezione. Come mai?
I valori dei nomi dei parametri nella firma dell'operazione fanno parte del contratto e fanno distinzione tra maiuscole e minuscole. Usare l'attributo System.ServiceModel.MessageParameterAttribute quando è necessario distinguere tra il nome del parametro locale e i metadati che descrivono l'operazione per le applicazioni client.
Sto usando uno dei miei strumenti di tracciamento e ottengo un'eccezione EndpointNotFoundException. Cosa sta succedendo?
Se si usa uno strumento di traccia che non è il meccanismo di traccia WCF fornito dal sistema e si riceve un valore EndpointNotFoundException che indica che si è verificato un problema di filtro degli indirizzi, è necessario usare la ClientViaBehavior classe per indirizzare i messaggi all'utilità di traccia e fare in modo che l'utilità reindirizzi tali messaggi all'indirizzo del servizio. La ClientViaBehavior classe modifica l'intestazione Via di indirizzamento per specificare l'indirizzo di rete successivo separatamente dal ricevitore finale, indicato dall'intestazione To di indirizzamento. In questo caso, tuttavia, non modificare l'indirizzo dell'endpoint, che viene utilizzato per determinare il valore To.
Nell'esempio di codice seguente viene illustrato un file di configurazione client di esempio.
<endpoint
address="http://localhost:8000/MyServer/"
binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IMyContract"
behaviorConfiguration="MyClient"
contract="IMyContract"
name="WSHttpBinding_IMyContract">
</endpoint>
<behaviors>
<endpointBehaviors>
<behavior name="MyClient">
<clientVia viaUri="http://localhost:8001/MyServer/"/>
</behavior>
</endpointBehaviors>
</behaviors>
Qual è l'indirizzo di base? In che modo è correlato a un indirizzo endpoint?
Un indirizzo di base è l'indirizzo radice di una ServiceHost classe. Per impostazione predefinita, se si aggiunge una ServiceMetadataBehavior classe alla configurazione del servizio, il linguaggio WSDL (Web Services Description Language) per tutti gli endpoint pubblicati dall'host viene recuperato dall'indirizzo di base HTTP, oltre a qualsiasi indirizzo relativo fornito al comportamento dei metadati, più "?wsdl". Se si ha familiarità con ASP.NET e IIS, l'indirizzo di base equivale alla directory virtuale.
Condivisione di una porta tra un endpoint di servizio e un endpoint mex tramite NetTcpBinding
Se si specifica l'indirizzo di base per un servizio come net.tcp://MyServer:8080/MyService e si aggiungono gli endpoint seguenti:
<services>
<service name="Microsoft.Samples.NetTcp.CalculatorService">
<endpoint address="calcsvc" binding ="netTcpBinding" contract="Microsoft.Samples.NetTcp.ICalculator"/>
<endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange" />
</service>
</services>
E se si modifica una delle impostazioni NetTcpBinding, come illustrato nel frammento di configurazione seguente:
<bindings>
<netTcpBinding>
<binding closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" transactionFlow="false" transferMode="Buffered" transactionProtocol="OleTransactions" hostNameComparisonMode="StrongWildcard" listenBacklog="10" maxBufferPoolSize="524288" maxBufferSize="65536" maxConnections="11" maxReceivedMessageSize="65536">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384"/>
<reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false"/>
<security mode="Transport">
<transport clientCredentialType="Windows" protectionLevel="EncryptAndSign"/>
</security>
</binding>
</netTcpBinding>
</bindings>
Verrà visualizzato un errore simile al seguente: Eccezione non gestita: System.ServiceModel.AddressAlreadyInUseException: Esiste già un listener nell'endpoint IP 0.0.0.0.0:9000 È possibile risolvere questo errore specificando un URL completo con una porta diversa per l'endpoint MEX, come illustrato nel frammento di configurazione seguente:
<services>
<service name="Microsoft.Samples.NetTcp.CalculatorService">
<endpoint address="calcsvc" binding ="netTcpBinding" contract="Microsoft.Samples.NetTcp.ICalculator"/>
<endpoint address="net.tcp://localhost:9001/servicemodelsamples/mex" binding="mexTcpBinding" contract="IMetadataExchange" />
</service>
</services>
Quando si chiama un'applicazione HTTP Web WCF da un'applicazione SOAP WCF, il servizio restituisce l'errore seguente: Metodo 405 non consentito
La chiamata a un'applicazione HTTP Web WCF (un servizio che usa WebHttpBinding e WebHttpBehavior) da un servizio WCF può generare l'eccezione seguente: Unhandled Exception: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: The remote server returned an unexpected response: (405) Method Not Allowed. questa eccezione si verifica perché WCF sovrascrive l'oggetto in uscita OperationContext con l'oggetto in ingresso OperationContext. Per risolvere questo problema, creare un oggetto OperationContextScope all'interno dell'operazione del servizio HTTP Web WCF. Per esempio:
public string Echo(string input)
{
using (new OperationContextScope(this.InnerChannel))
{
return base.Channel.Echo(input);
}
}