Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Thema wird eine Reihe bekannter Probleme aufgeführt, denen Kunden beim Entwickeln von WCF-Clients und -Diensten begegnet sind. Wenn das Problem, auf das Sie stoßen, nicht in dieser Liste enthalten ist, empfehlen wir, Tracing für Ihren Dienst zu konfigurieren. Dadurch wird eine Ablaufverfolgungsdatei generiert, die Sie mit dem Ablaufverfolgungsdatei-Viewer anzeigen und detaillierte Informationen zu Ausnahmen erhalten können, die innerhalb des Diensts auftreten können. Weitere Informationen zum Konfigurieren der Ablaufverfolgung finden Sie unter: Konfigurieren der Ablaufverfolgung. Weitere Informationen zum Protokolldatei-Anzeigeprogramm erhalten Sie im Service Trace Viewer Tool (SvcTraceViewer.exe).
-
HTTP-Fehler 404.3 – Nicht gefundenDie angeforderte Seite kann aufgrund der Erweiterungskonfiguration nicht bereitgestellt werden. Wenn es sich bei der Seite um ein Skript handelt, fügen Sie einen Handler hinzu. Wenn die Datei heruntergeladen werden soll, fügen Sie eine MIME-Zuordnung hinzu. Detaillierte Fehlerinformation für das Modul StaticFileModule.
Ich benutze eines meiner Verfolgungstools und erhalte eine EndpointNotFoundException. Was passiert?
Was ist die Basisadresse? Wie bezieht es sich auf eine Endpunktadresse?
Nach der Installation von Windows 7 und IIS wird beim Versuch, zu einem WCF-Dienst zu navigieren, die folgende Fehlermeldung angezeigt: HTTP-Fehler 404.3 – Nicht gefunden
Die vollständige Fehlermeldung lautet:
HTTP-Fehler 404.3 – Nicht gefundenDie angeforderte Seite kann aufgrund der Erweiterungskonfiguration nicht bereitgestellt werden. Wenn es sich bei der Seite um ein Skript handelt, fügen Sie einen Handler hinzu. Wenn die Datei heruntergeladen werden soll, fügen Sie eine MIME-Zuordnung hinzu. Detaillierte Fehlerinformation für das Modul StaticFileModule.
Diese Fehlermeldung tritt auf, wenn die "HTTP-Aktivierung von Windows Communication Foundation" in der Systemsteuerung nicht explizit festgelegt ist. Um dies festzulegen, wechseln Sie zur Systemsteuerung, klicken Sie in der unteren linken Ecke des Fensters auf "Programme". Klicken Sie auf "Windows-Features aktivieren oder deaktivieren". Erweitern Sie Microsoft .NET Framework 3.5.1, und wählen Sie die HTTP-Aktivierung von Windows Communication Foundation aus.
Manchmal erhalte ich eine MessageSecurityException für die zweite Anforderung, wenn mein Client nach der ersten Anforderung eine Weile im Leerlauf ist. Was passiert?
Die zweite Anforderung kann hauptsächlich aus zwei Gründen fehlschlagen: (1) die Sitzung ist abgelaufen oder (2) der Webserver, auf dem der Dienst gehostet wird, wurde zurückgesetzt. Im ersten Fall ist die Sitzung gültig, bis das Diensttimeout auftritt. Wenn der Dienst innerhalb des in der Bindung (ReceiveTimeout) des Diensts angegebenen Zeitraums keine Anforderung vom Client empfängt, beendet der Dienst die Sicherheitssitzung. Nachfolgende Clientnachrichten führen zu MessageSecurityException. Der Client muss eine sichere Sitzung mit dem Dienst erneut einrichten, um zukünftige Nachrichten zu senden oder ein zustandsbehaftetes Sicherheitskontexttoken zu verwenden. Zustandsbehaftete Sicherheitskontexttoken ermöglichen es außerdem, dass eine sichere Sitzung bestehen bleibt, wenn ein Webserver neu gestartet wird. Weitere Informationen zum Verwenden zustandsbehafteter sicherer Kontexttoken in einer sicheren Sitzung finden Sie unter How to: Create a Security Context Token for a Secure Session. Alternativ können Sie sichere Sitzungen deaktivieren. Wenn Sie die <wsHttpBinding-Bindung> verwenden, können Sie die establishSecurityContext Eigenschaft auf false festlegen, um sichere Sitzungen zu deaktivieren. Um sichere Sitzungen für andere Bindungen zu deaktivieren, müssen Sie eine benutzerdefinierte Bindung erstellen. Ausführliche Informationen zum Erstellen einer benutzerdefinierten Bindung finden Sie unter How to: Create a Custom Binding Using the SecurityBindingElement. Bevor Sie eine dieser Optionen anwenden, müssen Sie die Sicherheitsanforderungen Ihrer Anwendung verstehen.
Mein Dienst beginnt, neue Clients abzulehnen, nachdem etwa 10 Clients damit interagieren. Was passiert?
Standardmäßig können Dienste nur 10 gleichzeitige Sitzungen haben. Wenn die Dienstbindungen Sitzungen verwenden, akzeptiert der Dienst daher neue Clientverbindungen, bis er diese Zahl erreicht. Danach wird die Annahme neuer Clientverbindungen verweigert, bis eine der aktuellen Sitzungen endet. Sie können weitere Clients auf verschiedene Arten unterstützen. Wenn Ihr Dienst keine Sitzungen erfordert, sollten Sie keine sitzungsabhängige Bindung verwenden. (Weitere Informationen finden Sie unter Verwenden von Sitzungen.) Eine weitere Option besteht darin, den Sitzungsgrenzwert zu erhöhen, indem sie den Wert der MaxConcurrentSessions Eigenschaft auf die für Ihre Umstände geeignete Zahl ändert.
Kann ich meine Dienstkonfiguration von einer anderen Stelle als der Konfigurationsdatei der WCF-Anwendung laden?
Ja, Sie müssen jedoch eine benutzerdefinierte ServiceHost Klasse erstellen, die die ApplyConfiguration Methode überschreibt. Innerhalb dieser Methode können Sie zuerst die Basis zum Laden der Konfiguration aufrufen (wenn Sie auch die Standardkonfigurationsinformationen laden möchten), aber Sie können auch das Ladesystem für die Konfiguration vollständig ersetzen. Wenn Sie die Konfiguration aus einer Konfigurationsdatei laden möchten, die sich von der Anwendungskonfigurationsdatei unterscheidet, müssen Sie die Konfigurationsdatei selbst analysieren und die Konfiguration laden.
Das folgende Codebeispiel zeigt, wie die ApplyConfiguration Methode überlagert und direkt ein Endpunkt konfiguriert wird.
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;
}
}
Mein Dienst und Der Client funktionieren hervorragend, aber ich kann sie nicht zur Arbeit bringen, wenn sich der Client auf einem anderen Computer befindet? Was passiert?
Je nach Ausnahme können mehrere Probleme auftreten:
Möglicherweise müssen Sie die Clientendpunktadressen von localhost auf den Hostnamen ändern.
Möglicherweise müssen Sie den Port zur Anwendung öffnen. Ausführliche Informationen finden Sie unter Firewall-Anweisungen aus den SDK-Beispielen.
Weitere mögliche Probleme finden Sie im Beispielthema "Ausführen der Windows Communication Foundation-Beispiele".
Wenn Ihr Client Windows-Anmeldeinformationen verwendet und die Ausnahme ein SecurityNegotiationExceptionist, konfigurieren Sie Kerberos wie folgt.
Fügen Sie die Anmeldeinformationen für die Identität dem Endpunktelement in der Datei App.config des Clients hinzu:
<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>Führen Sie den selbst gehosteten Dienst unter dem System- oder NetworkService-Konto aus. Sie können diesen Befehl ausführen, um ein Befehlsfenster unter dem Systemkonto zu erstellen:
at 12:36 /interactive "cmd.exe"Hosten Sie den Dienst unter Internetinformationsdienste (IIS). Standardmäßig wird hier das Dienstprinzipalnamenkonto verwendet.
Registrieren Sie einen neuen SPN mit der Domäne mithilfe von SetSPN. Sie müssen ein Domänenadministrator sein, um dies zu tun.
Weitere Informationen zum Kerberos-Protokoll finden Sie unter Sicherheitskonzepte, die in WCF verwendet werden , und:
Beim Auslösen einer FaultException<Ausnahme>, deren Typ eine Ausnahme ist, erhalte ich immer einen allgemeinen FaultException-Typ auf dem Client, nicht den generischen Typ. Was passiert?
Es wird dringend empfohlen, einen eigenen benutzerdefinierten Fehlerdatentyp zu erstellen und als Detailtyp in Ihrem Fehlervertrag zu deklarieren. Der Grund hierfür ist die Verwendung von vom System bereitgestellten Ausnahmetypen:
Erstellt eine Typabhängigkeit, die eine der größten Stärken dienstorientierter Anwendungen entfernt.
Ausnahmen werden nicht notwendigerweise standardmäßig serialisiert. Einige – wie SecurityException- sind möglicherweise überhaupt nicht serialisierbar.
Macht interne Implementierungsdetails für Clients verfügbar. Weitere Informationen finden Sie unter Angeben und Behandeln von Fehlern in Verträgen und Diensten.
Wenn Sie jedoch eine Anwendung debuggen, können Sie Ausnahmeinformationen serialisieren und mithilfe der ServiceDebugBehavior Klasse an den Client zurückgeben.
Es scheint, als ob Einweg- und Anfrage-Antwort-Operationen ungefähr mit derselben Geschwindigkeit erfolgen, wenn die Antwort keine Daten enthält. Woran liegt das?
Die Angabe, dass ein Vorgang eine Möglichkeit ist, bedeutet nur, dass der Vorgangsvertrag eine Eingabemeldung akzeptiert und keine Ausgabemeldung zurückgibt. In WCF werden alle Clientaufrufe zurückgegeben, wenn die ausgehenden Daten zur Übertragung geschrieben wurden oder eine Ausnahme ausgelöst wurde. Unidirektionale Vorgänge funktionieren genauso. Außerdem können sie eine Ausnahme auslösen, falls der Dienst nicht gefunden wird, oder sie können blockiert werden, falls der Dienst nicht zur Annahme der Daten aus dem Netzwerk bereit ist. In WCF führt dies in der Regel zu unidirektionale Aufrufen, die schneller an den Client zurückgegeben werden als die Anforderungsantwort; aber jede Bedingung, die das Senden der ausgehenden Daten über das Netzwerk verlangsamt, verlangsamt unidirektionale Vorgänge sowie Anforderungsantwortvorgänge. Weitere Informationen finden Sie unter One-Way Services und Zugriff auf Dienste mit einem WCF-Client.
Ich verwende ein X.509-Zertifikat mit meinem Dienst und erhalte eine System.Security.Cryptography.CryptographicException. Was passiert?
Dies geschieht häufig nach dem Ändern des Benutzerkontos, unter dem der IIS-Arbeitsprozess ausgeführt wird. Wenn Sie beispielsweise in Windows XP das Standardbenutzerkonto ändern, unter dem die Aspnet_wp.exe von ASPNET ausgeführt wird, in ein benutzerdefiniertes Benutzerkonto, wird möglicherweise dieser Fehler angezeigt. Wenn Sie einen privaten Schlüssel verwenden, muss der Prozess, der ihn verwendet, über Berechtigungen für den Zugriff auf die Datei verfügen, die diesen Schlüssel speichert.
Wenn dies der Fall ist, müssen Sie dem Konto des Prozesses Lesezugriffsberechtigungen für die Datei mit dem privaten Schlüssel erteilen. Wenn beispielsweise der IIS-Arbeitsprozess unter dem Bob-Konto ausgeführt wird, müssen Sie Bob Lesezugriff auf die Datei gewähren, die den privaten Schlüssel enthält.
Weitere Informationen dazu, wie Sie dem richtigen Benutzerkonto Zugriff auf die Datei gewähren, die den privaten Schlüssel für ein bestimmtes X.509-Zertifikat enthält, finden Sie unter How to: Make X.509 Certificates Accessible to WCF.
Ich habe den ersten Parameter eines Vorgangs von Großbuchstaben in Kleinbuchstaben geändert; jetzt löst mein Client eine Ausnahme aus. Woran liegt das?
Die Werte der Parameternamen in der Vorgangssignatur sind Teil des Vertrags, und die Groß- und Kleinschreibung wird beachtet. Verwenden Sie das System.ServiceModel.MessageParameterAttribute Attribut, wenn Sie zwischen dem lokalen Parameternamen und den Metadaten unterscheiden müssen, die den Vorgang für Clientanwendungen beschreiben.
Ich benutze eines meiner Verfolgungstools und erhalte eine EndpointNotFoundException. Was passiert?
Wenn Sie ein Ablaufverfolgungstool verwenden, das nicht der vom System bereitgestellte WCF-Ablaufverfolgungsmechanismus ist, und Sie einen EndpointNotFoundException Hinweis darauf erhalten, dass eine Adressfilterabweichung vorliegt, müssen Sie die ClientViaBehavior Klasse verwenden, um die Nachrichten an das Ablaufverfolgungshilfsprogramm zu leiten und das Hilfsprogramm anzuweisen, diese Nachrichten an die Dienstadresse umzuleiten. Die ClientViaBehavior Klasse ändert den Via Adressheader, um die nächste Netzwerkadresse getrennt vom ultimativen Empfänger anzugeben, der durch den To Adressheader angegeben wird. Ändern Sie dabei jedoch nicht die Endpunktadresse, die zum Einrichten des To Werts verwendet wird.
Das folgende Codebeispiel zeigt eine Beispiel-Clientkonfigurationsdatei.
<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>
Was ist die Basisadresse? Wie bezieht es sich auf eine Endpunktadresse?
Eine Basisadresse ist die Stammadresse für eine ServiceHost Klasse. Wenn Sie ihrer Dienstkonfiguration eine ServiceMetadataBehavior Klasse hinzufügen, werden standardmäßig die Webdienstbeschreibungssprache (Web Services Description Language, WSDL) für alle Endpunkte, die der Host veröffentlicht, von der HTTP-Basisadresse abgerufen, sowie jede relative Adresse, die für das Metadatenverhalten bereitgestellt wird, sowie "?wsdl". Wenn Sie mit ASP.NET und IIS vertraut sind, entspricht die Basisadresse dem virtuellen Verzeichnis.
Gemeinsame Nutzung eines Ports zwischen einem Dienstendpunkt und einem mex-Endpunkt mithilfe des NetTcpBinding
Wenn Sie die Basisadresse für einen Dienst als net.tcp://MyServer:8080/MyService angeben und die folgenden Endpunkte hinzufügen:
<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>
Und wenn Sie eine der NetTcpBinding-Einstellungen ändern, wie im folgenden Konfigurationsausschnitt gezeigt:
<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>
Es wird ein Fehler wie folgt angezeigt: Unbehandelte Ausnahme: System.ServiceModel.AddressAlreadyInUseException: Es ist bereits ein Listener am IP-Endpunkt 0.0.0.0.0:9000 Sie können diesen Fehler umgehen, indem Sie eine vollqualifizierte URL mit einem anderen Port für den MEX-Endpunkt angeben, wie im folgenden Konfigurationsausschnitt gezeigt:
<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>
Beim Aufrufen einer WCF-Web-HTTP-Anwendung aus einer WCF-SOAP-Anwendung gibt der Dienst den folgenden Fehler zurück: 405-Methode nicht zulässig
Das Aufrufen einer WCF-Web-HTTP-Anwendung (ein Dienst, der WebHttpBinding und WebHttpBehavior verwendet) von einem WCF-Dienst aus kann die folgende Ausnahme generieren: Unhandled Exception: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: The remote server returned an unexpected response: (405) Method Not Allowed. Diese Ausnahme tritt auf, weil WCF den ausgehenden OperationContext mit dem eingehenden OperationContext überschreibt. Um dieses Problem zu lösen, erstellen Sie einen OperationContextScope innerhalb des WCF-Webdienstvorgangs. Beispiel:
public string Echo(string input)
{
using (new OperationContextScope(this.InnerChannel))
{
return base.Channel.Echo(input);
}
}