Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este tema se enumeran varias incidencias conocidas con las que los clientes se han encontrado al desarrollar clientes y servicios WCF. Si el problema con el que se encuentra no está en esta lista, le recomendamos que configure el seguimiento para su servicio. Esto generará un archivo de seguimiento que puede ver con el visor de archivos de seguimiento y obtendrá información detallada sobre las excepciones que pueden producirse en el servicio. Para obtener más información sobre cómo configurar el seguimiento, vea: Configuración del seguimiento. Para obtener más información sobre el visor de archivos de seguimiento, consulte: Service Trace Viewer Tool (SvcTraceViewer.exe).
-
Error HTTP 404.3: no encontradoLa página que solicita no se puede atender debido a la configuración de la extensión. Si la página es un script, agregue un controlador. Si se debe descargar el archivo, agregue un mapa MIME. Error detallado InformationModule StaticFileModule.
¿Cuál es la dirección base? ¿Cómo se relaciona con una dirección de punto de conexión?
Después de instalar Windows 7 e IIS, cuando intento examinar un servicio WCF obtengo el siguiente mensaje de error: Error HTTP 404.3: No encontrado
El mensaje de error completo es:
Error HTTP 404.3: no encontradoLa página que solicita no se puede atender debido a la configuración de la extensión. Si la página es un script, agregue un controlador. Si se debe descargar el archivo, agregue un mapa MIME. Error detallado InformationModule StaticFileModule.
Este mensaje de error se produce cuando "Activación HTTP de Windows Communication Foundation" no se establece explícitamente en el Panel de control. Para establecer esta opción en el Panel de control, haga clic en Programas en la esquina inferior izquierda de la ventana. Haga clic en Activar o desactivar características de Windows. Expanda Microsoft .NET Framework 3.5.1 y seleccione Activación HTTP de Windows Communication Foundation.
A veces recibo una excepción MessageSecurityException en la segunda solicitud si mi cliente está inactivo durante un tiempo después de la primera solicitud. ¿Qué pasa?
La segunda solicitud puede producir un error principalmente por dos motivos: (1) la sesión ha agotado el tiempo de espera o (2) se recicla el servidor web que hospeda el servicio. En el primer caso, la sesión es válida hasta que se agota el tiempo de espera del servicio. Cuando el servicio no recibe una solicitud del cliente dentro del período de tiempo especificado en el enlace del servicio (ReceiveTimeout), el servicio finaliza la sesión de seguridad. Los mensajes de cliente posteriores dan como resultado el MessageSecurityException. El cliente debe restablecer una sesión segura con el servicio para enviar los futuros mensajes o utilizar un token de contexto de seguridad con estado. Los tokens de contexto de seguridad con estado también permiten que una sesión segura sobreviva a un servidor web que se recicla. Para obtener más información sobre el uso de tokens de contexto seguro con estado en una sesión segura, vea How to: Create a Security Context Token for a Secure Session. Como alternativa, puede deshabilitar las sesiones seguras. Al usar el enlace <wsHttpBinding>, puede configurar la propiedad establishSecurityContext en false para deshabilitar las sesiones seguras. Para deshabilitar las sesiones seguras para otras vinculaciones, debe crear una vinculación personalizada. Para obtener más información sobre cómo crear un enlace personalizado, vea How to: Create a Custom Binding Using the SecurityBindingElement. Antes de aplicar cualquiera de estas opciones, debe comprender los requisitos de seguridad de la aplicación.
Mi servicio comienza a rechazar nuevos clientes después de que unos 10 clientes interactúen con él. ¿Qué pasa?
De forma predeterminada, los servicios solo pueden tener 10 sesiones simultáneas. Por lo tanto, si los enlaces de servicio usan sesiones, el servicio acepta nuevas conexiones de cliente hasta que alcanza ese número, después de lo cual rechaza las nuevas conexiones de cliente hasta que finalice una de las sesiones actuales. Puede atender a más clientes de diferentes maneras. Si su servicio no requiere sesiones, no utilice un enlace con sesión. (Para obtener más información, vea Uso de sesiones). Otra opción es aumentar el límite de sesión cambiando el valor de la MaxConcurrentSessions propiedad al número adecuado para su circunstancia.
¿Puedo cargar mi configuración de servicio desde algún lugar distinto del archivo de configuración de la aplicación WCF?
Sí, sin embargo, tiene que crear una clase ServiceHost personalizada que invalide el método ApplyConfiguration . Dentro de ese método, puede llamar a la base para cargar primero la configuración (si desea cargar también la información de configuración estándar), pero también puede reemplazar completamente el sistema de carga de configuración. Si desea cargar la configuración desde un archivo de configuración diferente del archivo de configuración de la aplicación, debe analizar el archivo de configuración usted mismo y cargar la configuración.
En el ejemplo de código siguiente se muestra cómo invalidar el ApplyConfiguration método y configurar directamente un punto de conexión.
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;
}
}
Mi servicio y cliente funcionan bien, pero no puedo conseguir que funcionen cuando el cliente está en otro equipo? ¿Qué pasa?
En función de la excepción, puede haber varios problemas:
Puede que necesite cambiar las direcciones de extremo del cliente al nombre de host y no el "localhost".
Puede que necesite abrir el puerto a la aplicación. Para obtener más información, consulte Instrucciones de firewall de los ejemplos del SDK.
Para ver otros posibles problemas, consulte el tema de Ejecutar los ejemplos de Windows Communication Foundation.
Si el cliente usa credenciales de Windows y la excepción es , SecurityNegotiationExceptionconfigure Kerberos como se indica a continuación.
Agregue las credenciales de identidad al elemento de punto de conexión en el archivo App.config del cliente:
<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>Ejecute el servicio autohospedado en la cuenta System o NetworkService. Puede ejecutar este comando para crear una ventana de comandos en la cuenta del sistema:
at 12:36 /interactive "cmd.exe"Hospede el servicio bajo IIS (Servicios de Internet Information Services) (IIS) que, de forma predeterminada, utiliza la cuenta del nombre de entidad de seguridad de servicio (SPN).
Registre un nuevo SPN con el dominio mediante SetSPN. Debe ser administrador de dominio para hacerlo.
Para obtener más información sobre el protocolo Kerberos, vea Conceptos de seguridad usados en WCF y:
Cuando lanzo una FaultException<Exception> donde el tipo es una excepción, siempre recibo un tipo FaultException general en el cliente y no el tipo genérico. ¿Qué pasa?
Se recomienda encarecidamente crear su propio tipo de datos de error personalizado y declararlo como tipo de detalle en el contrato de error. El motivo es que el uso de tipos de excepciones proporcionados por el sistema:
Crea una dependencia de tipo que elimina uno de los mayores puntos fuertes de las aplicaciones orientadas a servicios.
No se puede depender de que las excepciones se serialicen de forma estándar. Algunos, como SecurityException, pueden no ser serializables en absoluto.
Expone los detalles de implementación internos a los clientes. Para obtener más información, vea Especificar y controlar errores en contratos y servicios.
Si está depurando una aplicación, sin embargo, puede serializar información de excepción y devolverla al cliente utilizando la clase ServiceDebugBehavior .
Parece que las operaciones unidireccionales y de solicitud-respuesta se ejecutan a aproximadamente la misma velocidad cuando la respuesta no contiene datos. ¿Qué sucede?
Especificar que una operación es unidireccional significa solo que el contrato de operación acepta un mensaje de entrada y no devuelve un mensaje de salida. En WCF, todas las invocaciones del cliente vuelven cuando los datos salientes se han escrito en la conexión o se produce una excepción. Las operaciones unidireccionales funcionan de la misma manera y se pueden iniciar si el servicio no se puede localizar o se pueden bloquear si el servicio no está preparado para aceptar los datos de la red. Normalmente en WCF, esto produce llamadas unidireccionales que vuelven al cliente más rápidamente que la solicitud-respuesta; pero cualquier condición que ralentiza el envío de los datos salientes a través de la red ralentiza las operaciones unidireccionales, así como las operaciones de solicitud-respuesta. Para obtener más información, vea One-Way Services and Accessing Services Using a WCF Client.
Uso un certificado X.509 con mi servicio y obtengo una excepción System.Security.Cryptography.CryptographicException. ¿Qué pasa?
Esto suele ocurrir después de cambiar la cuenta de usuario con la que se ejecuta el proceso de trabajo de IIS. Por ejemplo, en Windows XP, si cambia la cuenta de usuario predeterminada en la que se ejecuta el Aspnet_wp.exe desde ASPNET a una cuenta de usuario personalizada, es posible que vea este error. Si usa una clave privada, el proceso que lo usa tendrá que tener permisos para acceder al archivo que almacena esa clave.
Si este es el caso, debe conceder privilegios de acceso de lectura a la cuenta del proceso para el archivo que contiene la clave privada. Por ejemplo, si el proceso de trabajo de IIS se ejecuta en la cuenta de Bob, deberá conceder a Bob acceso de lectura al archivo que contiene la clave privada.
Para obtener más información sobre cómo conceder acceso a la cuenta de usuario correcta al archivo que contiene la clave privada para un certificado X.509 específico, vea Cómo: Hacer que los certificados X.509 sean accesibles para WCF.
He cambiado el primer parámetro de una operación de mayúsculas a minúsculas; ahora mi cliente produce una excepción. ¿Qué sucede?
Los valores de los nombres de parámetro en la firma de la operación forma parte del contrato y distingue entre mayúsculas y minúsculas. Use el System.ServiceModel.MessageParameterAttribute atributo cuando necesite distinguir entre el nombre del parámetro local y los metadatos que describen la operación para las aplicaciones cliente.
Estoy usando una de mis herramientas de seguimiento y obtengo un EndpointNotFoundException. ¿Qué pasa?
Si usa una herramienta de seguimiento que no es el mecanismo de seguimiento WCF proporcionado por el sistema y recibe un EndpointNotFoundException que indica que hubo un error de coincidencia de filtro de direcciones, debe usar la ClientViaBehavior clase para dirigir los mensajes a la utilidad de seguimiento y hacer que la utilidad redirija esos mensajes a la dirección del servicio. La ClientViaBehavior clase modifica el Via encabezado de direccionamiento para especificar la siguiente dirección de red por separado del receptor final, indicado por el To encabezado de direccionamiento. Sin embargo, al hacerlo, no cambie la dirección del punto de conexión, que se usa para establecer el To valor.
En el ejemplo de código siguiente se muestra un archivo de configuración de cliente de ejemplo.
<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>
¿Cuál es la dirección base? ¿Cómo se relaciona con una dirección de punto de conexión?
Una dirección base es la dirección raíz de una ServiceHost clase. De forma predeterminada, si agrega una clase ServiceMetadataBehavior en su configuración de servicio, el lenguaje de descripción de servicios Web (WSDL) para todos los extremos que publica el host se recupera de la dirección base de HTTP, más cualquier dirección relativa proporcionada al comportamiento de los metadatos, más "? wsdl". Si está familiarizado con ASP.NET e IIS, la dirección base es equivalente al directorio virtual.
Uso compartido de un puerto entre un punto de conexión de servicio y un punto de conexión mex mediante NetTcpBinding
Si especifica la dirección base de un servicio como net.tcp://MyServer:8080/MyService y agrega los siguientes puntos de conexión:
<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>
Y si modifica una de las opciones de NetTcpBinding, como se muestra en el siguiente fragmento de código de configuración:
<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>
Verá un error como el siguiente: Excepción no controlada: System.ServiceModel.AddressAlreadyInUseException: Ya hay una escucha en el extremo IP0.0.0.0:9000. Para solucionar este error, especifique una dirección URL completa con un puerto diferente para el extremo MEX, como se muestra en el siguiente fragmento de código de configuración:
<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>
Al llamar a una aplicación WEB HTTP de WCF desde una aplicación SOAP de WCF, el servicio devuelve el siguiente error: Método 405 No permitido
Llamar a una aplicación web HTTP de WCF (un servicio que usa WebHttpBinding y WebHttpBehavior) desde un servicio WCF puede generar la excepción siguiente: Unhandled Exception: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: The remote server returned an unexpected response: (405) Method Not Allowed. Esta excepción se produce porque WCF sobrescribe el OperationContext saliente por el OperationContext entrante. Para solucionar este problema, cree un OperationContextScope elemento dentro de la operación del servicio HTTP web de WCF. Por ejemplo:
public string Echo(string input)
{
using (new OperationContextScope(this.InnerChannel))
{
return base.Channel.Echo(input);
}
}