WCF hibaelhárítási rövid útmutató
Ez a témakör felsorolja azokat az ismert problémákat, amelyekbe az ügyfelek a WCF-ügyfelek és -szolgáltatások fejlesztése során ütköztek. Ha az éppen futó probléma nem szerepel a listában, javasoljuk, hogy konfigurálja a szolgáltatás nyomkövetését. Ez létrehoz egy nyomkövetési fájlt, amelyet a nyomkövetési fájl megjelenítőjével tekinthet meg, és részletes információkat kap a szolgáltatásban esetleg előforduló kivételekről. A nyomkövetés konfigurálásával kapcsolatos további információkért lásd: Nyomkövetés konfigurálása. A nyomkövetési fájl megjelenítőjével kapcsolatos további információkért lásd: Service Trace Viewer Tool (SvcTraceViewer.exe).
-
404.3-os HTTP-hiba – Nem találhatóA kért lap nem kézbesíthető a bővítménykonfiguráció miatt. Ha a lap szkript, adjon hozzá egy kezelőt. Ha a fájlt le kell tölteni, adjon hozzá egy MIME-térképet. Részletes hibainformációModule StaticFileModule.
A szolgáltatásom körülbelül 10 ügyfél kezelése után kezdi elutasítani az új ügyfeleket. Mi történik?
Betölthetem a szolgáltatáskonfigurációmat a WCF-alkalmazás konfigurációs fájljától eltérő helyről?
Mi az alapcím? Hogyan kapcsolódik egy végpontcímhez?
A Windows 7 és az IIS telepítése után, amikor megkísérlek megkeresni egy WCF szolgáltatást, a következő hibaüzenet jelenik meg: HTTP-hiba 404.3 – Nem található
A teljes hibaüzenet a következő:
404.3-os HTTP-hiba – Nem találhatóA kért lap nem kézbesíthető a bővítménykonfiguráció miatt. Ha a lap szkript, adjon hozzá egy kezelőt. Ha a fájlt le kell tölteni, adjon hozzá egy MIME-térképet. Részletes hibainformációModule StaticFileModule.
Ez a hibaüzenet akkor jelenik meg, ha a "Windows Communication Foundation HTTP-aktiválás" nincs explicit módon beállítva a Vezérlőpult. A Vezérlőpult beállításához kattintson az ablak bal alsó sarkában található Programok elemre. Kattintson a Windows-szolgáltatások be- és kikapcsolása gombra. Bontsa ki a Microsoft .NET-keretrendszer 3.5.1-et, és válassza a Windows Communication Foundation HTTP-aktiválását.
Néha egy MessageSecurityException hibaüzenetet kapok a második kérésnél, ha az ügyfelem egy ideig tétlen az első kérés után. Mi történik?
A második kérés elsősorban két okból meghiúsulhat: (1) a munkamenet túllépte az időkorlátot, vagy (2) a szolgáltatást üzemeltető webkiszolgáló újraindul. Az első esetben a munkamenet érvényes, amíg a szolgáltatás túllépi az időkorlátot. Ha a szolgáltatás nem kap kérést az ügyféltől a szolgáltatás kötésében (ReceiveTimeout) megadott időn belül, a szolgáltatás leállítja a biztonsági munkamenetet. Az ezt követő ügyfélüzenetek a következőt eredményezik MessageSecurityException: . Az ügyfélnek újra létre kell hoznia egy biztonságos munkamenetet a szolgáltatással a jövőbeli üzenetek küldéséhez vagy egy állapotalapú biztonsági környezet jogkivonatának használatához. Az állapotalapú biztonsági környezet jogkivonatai azt is lehetővé teszik, hogy egy biztonságos munkamenet túléljen egy újrafeldolgozott webkiszolgálót. Az állapotalapú biztonságos környezet jogkivonatainak biztonságos munkamenetben való használatával kapcsolatos további információkért lásd : Biztonsági környezeti jogkivonat létrehozása biztonságos munkamenethez. Másik lehetőségként letilthatja a biztonságos munkameneteket. A wsHttpBinding> kötés használatakor <beállíthatja a tulajdonságot false a establishSecurityContext biztonságos munkamenetek letiltására. Ha más kötések biztonságos munkameneteit szeretné letiltani, létre kell hoznia egy egyéni kötést. Az egyéni kötések létrehozásával kapcsolatos részletekért lásd : Egyéni kötés létrehozása a SecurityBindingElement használatával. A fenti beállítások alkalmazása előtt ismernie kell az alkalmazás biztonsági követelményeit.
A szolgáltatásom körülbelül 10 ügyfél kezelése után kezdi elutasítani az új ügyfeleket. Mi történik?
Alapértelmezés szerint a szolgáltatások csak 10 egyidejű munkamenetet tartalmazhatnak. Ezért ha a szolgáltatáskötések munkameneteket használnak, a szolgáltatás addig fogadja az új ügyfélkapcsolatokat, amíg el nem éri ezt a számot, majd elutasítja az új ügyfélkapcsolatokat, amíg az aktuális munkamenetek valamelyike véget nem ér. Több ügyfelet többféleképpen is támogathat. Ha a szolgáltatás nem igényel munkameneteket, ne használjon munkamenet-kötést. (További információ: Munkamenetek használata.) Egy másik lehetőség a munkamenet-korlát növelése úgy, hogy a MaxConcurrentSessions tulajdonság értékét a körülményeknek megfelelő számra módosítja.
Betölthetem a szolgáltatáskonfigurációmat a WCF-alkalmazás konfigurációs fájljától eltérő helyről?
Igen, azonban létre kell hoznia egy egyéni ServiceHost osztályt, amely felülírja a metódust ApplyConfiguration . Ebben a módszerben meghívhatja az alapt, hogy először betöltse a konfigurációt (ha a standard konfigurációs adatokat is be szeretné tölteni), de teljes mértékben lecserélheti a konfigurációbetöltő rendszert is. Ha az alkalmazáskonfigurációs fájltól eltérő konfigurációs fájlból szeretné betölteni a konfigurációt, saját maga kell elemeznie a konfigurációs fájlt, és be kell töltenie a konfigurációt.
Az alábbi példakód bemutatja, hogyan bírálhatja felül a metódust ApplyConfiguration , és hogyan konfigurálhat közvetlenül egy végpontot.
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;
}
}
A szolgáltatásom és az ügyfél nagyszerűen működik, de nem tudom elérni őket, hogy működjenek, ha az ügyfél egy másik számítógépen van? Mi történik?
A kivételtől függően több probléma is lehet:
Előfordulhat, hogy az ügyfélvégpont-címeket nem a "localhost" nevére, hanem a gazdagép nevére kell módosítania.
Előfordulhat, hogy meg kell nyitnia a portot az alkalmazásnak. További részletekért tekintse meg az SDK-minták tűzfalutasítását .
További lehetséges problémákért tekintse meg a Windows Kommunikációs alapminták futtatása című minta témakört.
Ha az ügyfél Windows-hitelesítő adatokat használ, és a kivétel a SecurityNegotiationExceptionkövetkező, konfigurálja a Kerberost az alábbiak szerint.
Adja hozzá az identitás hitelesítő adatait az ügyfél App.config fájljának végponteleméhez:
<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>Futtassa a saját üzemeltetésű szolgáltatást a System vagy NetworkService fiók alatt. Ezt a parancsot futtatva létrehozhat egy parancsablakot a Rendszerfiók alatt:
at 12:36 /interactive "cmd.exe"Üzemeltetheti a szolgáltatást az Internet Information Services (IIS) alatt, amely alapértelmezés szerint a szolgáltatásnév (SPN) fiókot használja.
Regisztráljon egy új egyszerű szolgáltatásnevet a tartományhoz a SetSPN használatával. Ehhez tartományadminisztrátornak kell lennie.
A Kerberos protokollról további információt a WCF-ben használt biztonsági fogalmak és a következő témakörben talál:
Amikor olyan FaultException<kivételt> adok ki, ahol a típus kivétel, mindig általános FaultException típust kapok az ügyfélen, és nem az általános típust. Mi történik?
Javasoljuk, hogy hozzon létre saját egyéni hibaadattípust, és deklarálja azt a hibaszerződés részlettípusaként. Ennek az az oka, hogy a rendszer által biztosított kivételtípusok használata:
Létrehoz egy típusfüggőséget, amely eltávolítja a szolgáltatásorientált alkalmazások egyik legnagyobb erősségeit.
Nem függhet a szokásos módon szerializált kivételektől. Néhány – például SecurityException– lehet, hogy egyáltalán nem szerializálható.
A belső megvalósítás részleteit teszi elérhetővé az ügyfelek számára. További információ: Szerződések és szolgáltatások hibáinak megadása és kezelése.
Ha azonban hibakereséssel keres egy alkalmazást, szerializálhatja a kivételadatokat, és az osztály használatával visszaküldheti az ServiceDebugBehavior ügyfélnek.
Úgy tűnik, hogy az egyirányú és a kérés-válasz műveletek nagyjából ugyanolyan sebességgel térnek vissza, amikor a válasz nem tartalmaz adatokat. Mi történik?
Ha egy művelet egy módon van megadva, az csak azt jelenti, hogy a műveleti szerződés elfogad egy bemeneti üzenetet, és nem ad vissza kimeneti üzenetet. A WCF-ben az ügyfélhívások akkor térnek vissza, ha a kimenő adatokat a vezetékre írták, vagy kivételt jeleznek. Az egyirányú műveletek ugyanúgy működnek, és dobhatnak, ha a szolgáltatás nem található vagy blokkolható, ha a szolgáltatás nem áll készen az adatok elfogadására a hálózatról. Ez általában a WCF-ben egyirányú hívásokat eredményez, amelyek gyorsabban térnek vissza az ügyfélhez, mint a kérés-válasz; de minden olyan feltétel, amely lelassítja a kimenő adatok hálózaton keresztüli küldését, lelassítja az egyirányú műveleteket, valamint a kérés-válasz műveleteket. További információ: One-Way Services and Accessing Services Using a WCF Client.
X.509-tanúsítványt használok a szolgáltatásommal, és egy System.Security.Cryptography.CryptographicException tanúsítványt kapok. Mi történik?
Ez általában annak a felhasználói fióknak a módosítása után fordul elő, amely alatt az IIS-feldolgozó folyamat fut. Ha például a Windows XP rendszerben módosítja az alapértelmezett felhasználói fiókot, amely alatt a Aspnet_wp.exe fut az ASPNET-ről egy egyéni felhasználói fiókra, akkor ez a hiba jelenhet meg. Titkos kulcs használata esetén az azt használó folyamatnak engedélyekkel kell rendelkeznie a kulcs tárolására használt fájl eléréséhez.
Ebben az esetben olvasási hozzáférési jogosultságokat kell adnia a folyamat fiókjának a titkos kulcsot tartalmazó fájlhoz. Ha például az IIS-feldolgozó folyamat a Bob-fiók alatt fut, akkor olvasási hozzáférést kell adnia Bobnak a titkos kulcsot tartalmazó fájlhoz.
Az X.509-tanúsítványok akadálymentessé tétele a WCF számára című témakörben talál további információt arról, hogyan adhat hozzáférést a megfelelő felhasználói fióknak ahhoz a fájlhoz, amely egy adott X.509-tanúsítvány titkos kulcsát tartalmazza.
A művelet első paraméterét nagybetűsről kisbetűsre módosítottam; Most az ügyfelem kivételt vet ki. Mi történik?
A műveleti aláírásban szereplő paraméternevek értékei a szerződés részét képezik, és megkülönböztetik a kis- és nagybetűket. Használja az System.ServiceModel.MessageParameterAttribute attribútumot, ha meg kell különböztetnie a helyi paraméter nevét és az ügyfélalkalmazások műveletét leíró metaadatokat.
Az egyik nyomkövetési eszközömet használom, és az EndpointNotFoundException parancsot kapom. Mi történik?
Ha olyan nyomkövetési eszközt használ, amely nem a rendszer által biztosított WCF nyomkövetési mechanizmus, és olyan üzenetet kap EndpointNotFoundException , amely azt jelzi, hogy a címszűrő nem egyezik, az osztályt kell használnia ClientViaBehavior az üzenetek nyomkövetési segédprogramhoz való irányításához, és a segédprogramnak át kell irányítania ezeket az üzeneteket a szolgáltatás címére. Az ClientViaBehavior osztály módosítja a Via címzési fejlécet, hogy a végső fogadótól elkülönítve adja meg a következő hálózati címet, amelyet a To címzési fejléc jelez. Ennek során azonban ne módosítsa a végpont címét, amely az To érték meghatározására szolgál.
Az alábbi példakód egy ügyfélkonfigurációs fájlt mutat be.
<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>
Mi az alapcím? Hogyan kapcsolódik egy végpontcímhez?
Az alapcím egy osztály gyökércíme ServiceHost . Alapértelmezés szerint, ha osztályt ServiceMetadataBehavior ad hozzá a szolgáltatáskonfigurációhoz, a rendszer lekéri a webszolgáltatások leírási nyelvét (WSDL) az összes végponthoz, amelyet a gazdagép közzétesz a HTTP-alapcímről, valamint a metaadatok viselkedéséhez megadott relatív címeket, valamint a "?wsdl"-t. Ha ismeri a ASP.NET és az IIS-t, az alapcím egyenértékű a virtuális könyvtárral.
Port megosztása egy szolgáltatásvégpont és egy mex végpont között a NetTcpBinding használatával
Ha egy szolgáltatás alapcímét net.tcp://MyServer:8080/MyService néven adja meg, és adja hozzá a következő végpontokat:
<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>
És ha módosítja a NetTcpBinding egyik beállítását az alábbi konfigurációs kódrészletben látható módon:
<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>
A következőhöz hasonló hibaüzenet jelenik meg: Nem kezelt kivétel: System.ServiceModel.AddressAlreadyInUseException: Már van figyelő a 0.0.0.0:9000 IP-végponton. Ezt a hibát úgy háríthatja el, hogy egy teljesen minősített URL-címet ad meg egy másik porttal a MEX-végponthoz, ahogyan az a következő konfigurációs kódrészletben látható:
<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>
WCF-web HTTP-alkalmazás WCF SOAP-alkalmazásból való meghívásakor a szolgáltatás a következő hibát adja vissza: 405 Metódus nem engedélyezett
Egy WCF-web HTTP-alkalmazás meghívása (amely egy WCF-szolgáltatásból használja az WebHttpBinding és WebHttpBehavior) a következő kivételt okozhatja: Unhandled Exception: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: The remote server returned an unexpected response: (405) Method Not Allowed. Ez a kivétel azért fordul elő, mert a WCF felülírja a kimenő adatokat OperationContext a bejövővel OperationContext. A probléma megoldásához hozzon létre egy OperationContextScope műveletet a WCF webes HTTP-szolgáltatásában. Példa:
public string Echo(string input)
{
using (new OperationContextScope(this.InnerChannel))
{
return base.Channel.Echo(input);
}
}