Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym temacie wymieniono szereg znanych problemów, które klienci napotkali podczas opracowywania klientów i usług WCF. Jeśli problem, w którym się znajdujesz, nie znajduje się na tej liście, zalecamy skonfigurowanie śledzenia dla usługi. Spowoduje to wygenerowanie pliku śledzenia, który można wyświetlić za pomocą przeglądarki plików śledzenia i uzyskać szczegółowe informacje o wyjątkach, które mogą występować w usłudze. Aby uzyskać więcej informacji na temat konfigurowania śledzenia, zobacz: Konfigurowanie śledzenia. Aby uzyskać więcej informacji na temat przeglądarki plików śledzenia, zobacz: Service Trace Viewer Tool (SvcTraceViewer.exe).
-
Błąd HTTP 404.3 — nie znalezionoStrona żądana nie może być obsługiwana z powodu konfiguracji rozszerzenia. Jeśli strona jest skryptem, dodaj procedurę obsługi. Jeśli plik powinien zostać pobrany, dodaj mapę MIME. Szczegółowe informacje o błędzie modułu StaticFileModule.
Czy mogę załadować konfigurację usługi z innego miejsca niż plik konfiguracji aplikacji WCF?
Jaki jest adres podstawowy? Jak odnosi się on do adresu punktu końcowego?
Po zainstalowaniu systemu Windows 7 i usług IIS podczas próby przeglądania usługi WCF pojawia się następujący komunikat o błędzie: Błąd HTTP 404.3 — Nie znaleziono
Komunikat o błędzie jest następujący:
Błąd HTTP 404.3 — nie znalezionoStrona żądana nie może być obsługiwana z powodu konfiguracji rozszerzenia. Jeśli strona jest skryptem, dodaj procedurę obsługi. Jeśli plik powinien zostać pobrany, dodaj mapę MIME. Szczegółowe informacje o błędzie modułu StaticFileModule.
Ten komunikat o błędzie występuje, gdy "Aktywacja HTTP programu Windows Communication Foundation" nie jest jawnie ustawiona w Panelu sterowania. Aby to ustawić, przejdź do Panelu sterowania i kliknij Programy w lewym dolnym rogu okna. Kliknij pozycję Włącz lub wyłącz funkcje systemu Windows. Rozwiń węzeł Microsoft .NET Framework 3.5.1 i wybierz opcję Aktywacja HTTP w Windows Communication Foundation.
Czasami otrzymuję komunikat MessageSecurityException w drugim żądaniu, jeśli mój klient jest bezczynny przez pewien czas po pierwszym żądaniu. Co się dzieje?
Drugie żądanie może zakończyć się niepowodzeniem głównie z dwóch powodów: (1) upłynął limit czasu sesji lub (2) serwer sieci Web hostujący usługę został ponownie uruchomiony. W pierwszym przypadku sesja jest prawidłowa do czasu upłynął limit czasu usługi. Gdy usługa nie odbiera żądania od klienta w okresie określonym w powiązaniu usługi (ReceiveTimeout), usługa kończy sesję zabezpieczeń. Kolejne komunikaty klienta powodują wyświetlenie polecenia MessageSecurityException. Klient musi ponownie ustanowić bezpieczną sesję z usługą, aby wysyłać przyszłe komunikaty lub używać stanowego tokenu kontekstu zabezpieczeń. Stanowe tokeny kontekstu zabezpieczeń umożliwiają również bezpieczną sesję, aby przetrwać ponowne uruchomienie serwera sieci Web. Aby uzyskać więcej informacji na temat używania stanowych tokenów kontekstu bezpiecznego w bezpiecznej sesji, zobacz Instrukcje: tworzenie tokenu kontekstu zabezpieczeń na potrzeby bezpiecznej sesji. Alternatywnie można wyłączyć bezpieczne sesje. Jeśli używasz <powiązania wsHttpBinding>, możesz ustawić właściwość establishSecurityContext na false w celu wyłączenia bezpiecznych sesji. Aby wyłączyć bezpieczne sesje dla innych powiązań, należy utworzyć powiązanie niestandardowe. Aby uzyskać szczegółowe informacje na temat tworzenia powiązania niestandardowego, zobacz How to: Create a Custom Binding Using the SecurityBindingElement (Instrukcje: tworzenie powiązania niestandardowego przy użyciu elementu SecurityBindingElement). Przed zastosowaniem dowolnej z tych opcji należy zrozumieć wymagania dotyczące zabezpieczeń aplikacji.
Moja usługa zaczyna odrzucać nowych klientów po tym, jak około 10 klientów wchodzi z nim w interakcję. Co się dzieje?
Domyślnie usługi mogą mieć tylko 10 współbieżnych sesji. W związku z tym, jeśli powiązania usługi używają sesji, usługa akceptuje nowe połączenia klienckie, dopóki nie osiągnie tej liczby, po czym odmawia nowych połączeń do momentu zakończenia jednej z bieżących sesji. Więcej klientów można obsługiwać na wiele sposobów. Jeśli usługa nie wymaga sesji, nie używaj powiązania sesji. (Aby uzyskać więcej informacji, zobacz Używanie sesji). Inną opcją jest zwiększenie limitu sesji przez zmianę wartości MaxConcurrentSessions właściwości na liczbę odpowiednią dla danej okoliczności.
Czy mogę załadować konfigurację usługi z innego miejsca niż plik konfiguracji aplikacji WCF?
Tak, należy jednak utworzyć klasę niestandardową ServiceHost , która zastępuje metodę ApplyConfiguration . Wewnątrz tej metody można najpierw wywołać bazę, aby załadować konfigurację (jeśli chcesz załadować standardowe informacje o konfiguracji), ale można również całkowicie zastąpić system ładowania konfiguracji. Jeśli chcesz załadować konfigurację z pliku konfiguracji innego niż plik konfiguracji aplikacji, musisz samodzielnie przeanalizować plik konfiguracji i załadować konfigurację.
Poniższy przykład kodu pokazuje, jak zastąpić metodę ApplyConfiguration i bezpośrednio skonfigurować punkt końcowy.
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;
}
}
Moja usługa i klient działają świetnie, ale nie mogę dostać ich do pracy, gdy klient jest na innym komputerze? Co się dzieje?
W zależności od wyjątku może wystąpić kilka problemów:
Może być konieczne zmianę adresów punktów końcowych klienta na nazwę hosta, a nie na "localhost".
Może być konieczne otwarcie portu w aplikacji. Aby uzyskać szczegółowe informacje, zobacz Instrukcje zapory z przykładów zestawu SDK.
Aby uzyskać informacje o innych możliwych problemach, zobacz temat Przykłady dotyczące uruchamiania przykładów programu Windows Communication Foundation.
Jeśli klient używa poświadczeń systemu Windows, a wyjątek to SecurityNegotiationException, skonfiguruj protokół Kerberos w następujący sposób.
Dodaj poświadczenia tożsamości do elementu punktu końcowego w pliku App.config klienta:
<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>Uruchom usługę samodzielnie hostowaną na koncie „System” lub „NetworkService”. To polecenie można uruchomić, aby utworzyć okno polecenia w ramach konta systemowego:
at 12:36 /interactive "cmd.exe"Utrzymuj usługę w środowisku Internet Information Services (IIS), które domyślnie używa konta SPN (Service Principal Name).
Zarejestruj nową nazwę SPN w domenie przy użyciu programu SetSPN. Aby to zrobić, musisz być administratorem domeny.
Aby uzyskać więcej informacji na temat protokołu Kerberos, zobacz Pojęcia dotyczące zabezpieczeń używane w programie WCF i:
Gdy zgłaszam wyjątek typu FaultException<Exception>, gdzie typ jest wyjątkiem, na kliencie zawsze otrzymuję ogólny typ FaultException, a nie typ ogólny. Co się dzieje?
Zdecydowanie zaleca się utworzenie własnego niestandardowego typu danych błędu i zadeklarowanie go jako typ szczegółów w kontrakcie błędu. Przyczyną jest użycie typów wyjątków dostarczonych przez system:
Tworzy zależność typu, która usuwa jedną z największych zalet aplikacji zorientowanych na usługi.
Nie można polegać na tym, że wyjątki będą serializowane w standardowy sposób. Niektóre — na przykład SecurityException— mogą nie być serializowalne w ogóle.
Uwidacznia szczegóły implementacji wewnętrznej klientom. Aby uzyskać więcej informacji, zobacz Określanie i obsługa błędów w kontraktach i usługach.
Jeśli jednak debugujesz aplikację, możesz serializować informacje o wyjątkach i zwracać je do klienta przy użyciu ServiceDebugBehavior klasy .
Wygląda na to, że operacje jednokierunkowe i odpowiedzi na żądanie wykonują się w mniej więcej takim samym tempie, gdy odpowiedź nie zawiera żadnych danych. Co się dzieje?
Określenie, że operacja jest jednym ze sposobów oznacza tylko, że kontrakt operacji akceptuje komunikat wejściowy i nie zwraca komunikatu wyjściowego. W WCF wszystkie wywołania klienta kończą się, gdy dane wychodzące zostaną zapisane w kanale lub gdy zgłoszony zostanie wyjątek. Operacje jednokierunkowe działają w taki sam sposób i mogą zgłaszać wyjątki, jeśli usługa nie może być zlokalizowana, lub zatrzymywać się, jeśli usługa nie jest przygotowana do akceptowania danych z sieci. Zazwyczaj w programie WCF powoduje to, że jednokierunkowe wywołania zwracają się do klienta szybciej niż żądanie-odpowiedź; ale każdy warunek, który spowalnia wysyłanie danych wychodzących przez sieć spowalnia operacje jednokierunkowe, a także operacje żądania-odpowiedź. Aby uzyskać więcej informacji, zobacz One-Way Services and Accessing Services Using a WCF Client (Usługi i uzyskiwanie dostępu do usług przy użyciu klienta WCF).
Posługuję się certyfikatem X.509 w mojej usłudze i otrzymuję wyjątek System.Security.Cryptography.CryptographicException. Co się dzieje?
Dzieje się tak często po zmianie konta użytkownika, w ramach którego jest uruchamiany proces roboczy usług IIS. Na przykład w systemie Windows XP, jeśli zmienisz domyślne konto użytkownika, w którym Aspnet_wp.exe działa z platformy ASPNET na niestandardowe konto użytkownika, może zostać wyświetlony ten błąd. W przypadku korzystania z klucza prywatnego proces, który go używa, będzie musiał mieć uprawnienia dostępu do pliku przechowującego ten klucz.
W takim przypadku musisz przyznać uprawnienia dostępu do odczytu do konta procesu dla pliku zawierającego klucz prywatny. Jeśli na przykład proces roboczy usług IIS jest uruchomiony w ramach konta Boba, musisz przyznać Bobowi dostęp do odczytu do pliku zawierającego klucz prywatny.
Aby uzyskać więcej informacji o sposobie udzielenia poprawnego dostępu do pliku zawierającego klucz prywatny dla określonego certyfikatu X.509, zobacz How to: Make X.509 Certificates Accessible to WCF (Instrukcje: udostępnianie certyfikatów X.509 w programie WCF).
Zmieniłem pierwszy parametr operacji z wielkich liter na małe litery; teraz mój klient zgłasza wyjątek. Co się dzieje?
Wartości nazw parametrów w sygnaturze operacji są częścią kontraktu i uwzględniają wielkość liter. Użyj atrybutu System.ServiceModel.MessageParameterAttribute , jeśli musisz odróżnić nazwę parametru lokalnego od metadanych opisujących operację dla aplikacji klienckich.
Używam jednego z moich narzędzi do śledzenia i otrzymuję wyjątek EndpointNotFoundException. Co się dzieje?
Jeśli używasz narzędzia do śledzenia, które nie jest mechanizmem śledzenia WCF dostarczonego przez system i otrzymujesz komunikat EndpointNotFoundException wskazujący, że wystąpiła niezgodność filtru adresów, należy użyć ClientViaBehavior klasy , aby skierować komunikaty do narzędzia śledzenia i mieć narzędzie przekierowujące te komunikaty do adresu usługi. Klasa ClientViaBehavior zmienia nagłówek adresowania Via, aby oddzielnie określić następny adres sieciowy i końcowego odbiorcę, jak wskazuje nagłówek adresowania To. W takim przypadku nie należy jednak zmieniać adresu punktu końcowego, który jest używany do ustanowienia To wartości.
Poniższy przykładowy kod przedstawia przykładowy plik konfiguracji klienta.
<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>
Jaki jest adres podstawowy? Jak odnosi się on do adresu punktu końcowego?
Adres podstawowy to adres ServiceHost główny klasy. Domyślnie, jeśli dodasz klasę ServiceMetadataBehavior do konfiguracji usługi, język opisu usług sieci Web (WSDL) dla wszystkich punktów końcowych publikowanych przez hosta są pobierane z adresu podstawowego HTTP, a także wszelkie adresy względne podane do zachowania metadanych oraz "?wsdl". Jeśli znasz ASP.NET i usługi IIS, adres podstawowy jest odpowiednikiem katalogu wirtualnego.
Udostępnianie portu między punktem końcowym usługi a punktem końcowym mex przy użyciu narzędzia NetTcpBinding
Jeśli określisz podstawowy adres usługi jako net.tcp://MyServer:8080/MyService i dodaj następujące punkty końcowe:
<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>
Jeśli zmodyfikujesz jedno z ustawień NetTcpBinding, jak pokazano w poniższym fragmencie konfiguracji:
<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>
Zobaczysz błąd podobny do następującego: Nieobsługiwany wyjątek: System.ServiceModel.AddressAlreadyInUseException: Istnieje już nasłuch na punkcie końcowym IP 0.0.0.0:9000 Można obejść ten błąd, określając w pełni kwalifikowany adres URL z innym portem dla punktu końcowego MEX, jak pokazano w poniższym fragmencie konfiguracji.
<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>
Podczas wywoływania internetowej aplikacji HTTP programu WCF z aplikacji protokołu SOAP WCF usługa zwraca następujący błąd: 405 Metoda niedozwolona
Wywołanie aplikacji sieci Web HTTP programu WCF (usługi korzystającej z parametrów WebHttpBinding i WebHttpBehavior) z usługi WCF może wygenerować następujący wyjątek: Unhandled Exception: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: The remote server returned an unexpected response: (405) Method Not Allowed. Ten wyjątek występuje, ponieważ program WCF zastępuje wychodzące OperationContext z przychodzącym OperationContext elementem. Aby rozwiązać ten problem, utwórz element OperationContextScope w ramach operacji protokołu HTTP sieci Web WCF. Przykład:
public string Echo(string input)
{
using (new OperationContextScope(this.InnerChannel))
{
return base.Channel.Echo(input);
}
}