[SilverLight] NotFound Exception

Una de las mayores desventajas que nos podemos encontrar en SilverLight es la depuración de errores, en especial si estamos usando servicio WCF con RIA. Siempre podemos depurar la aplicación SilverLight cuando usemos Visual Studio, pero el problema es cuando disponemos de un servicio correctamente desplegado en IIS y nuestra aplicación falla al conectarse al servicio. El error más común al lanzar nuestra aplicación que se conecta a un servicio es una excepción de WCF indicando lo siguiente:

   1: {System.Net.WebException: El servidor remoto devolvió un error: NotFound. ---> System.Net.WebException: El servidor remoto devolvió un error: NotFound.

   2:    en System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)

   3:    en System.Net.Browser.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)

   4:    en System.Net.Browser.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)

   5:    --- Fin del seguimiento de la pila de excepciones internas ---

   6:    en System.Net.Browser.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)

   7:    en System.Net.Browser.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)

   8:    en System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelAsyncRequest.CompleteGetResponse(IAsyncResult result)}

Para ver qué esta ocurriendo realmente debemos realizar los siguientes pasos:

1 – Debemos asegurarnos que nuestro servicio está creado perfectamente dentro del servidor (accediendo al servicio a través del mismo para comprobar que se ha creado correctamente).

2 – Verificar si el ámbito del servicio y nuestra aplicación es el mismo. En el caso de que no lo sea, debemos especificar las políticas de acceso de dos modos: uno para las aplicaciones SilverLight y otro para el estándar de Adobe (como bien se indica en este artículo para SilverLight y este otro para dominios cruzados )

3 – Por último nos queda establecer una directiva para poder imprimir la traza. La excepción de NotFound es un tanto ambigua, ya que aparentemente indica que no ha encontrado el servicio pero no indica por qué. Antes de dedicarse mucho tiempo a analizar la configuración del cliente y el servidor conviene primero imprimir la traza del error para conocer de primera mano qué es lo que impide al cliente conectarse con el servicio. Para ello debemos indicarlo expresamente mediante las siguientes líneas en el web.config (fichero de configuración del lado servidor):

 

<system.serviceModel>

    <diagnostics>
      <messageLogging logEntireMessage="true"
        maxMessagesToLog="300"
        logMessagesAtServiceLevel="false"
        logMalformedMessages="true"
        logMessagesAtTransportLevel="true" />
    </diagnostics>

…

</system.serviceModel>

Poca explicación se puede añadir a esas líneas. Únicamente le estamos indicando que queremos activar el sistema de log, las características de los que admitimos y la capacidad del log.

Por otra parte tenemos que añadir el siguiente nodo al XML:

<system.diagnostics>
    <sources>
      <source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
        <listeners>
         <add name="xml" type="System.Diagnostics.XmlWriterTraceListener"
           initializeData="c:\Temp\WcfMessage.log" />
        </listeners>
      </source>
    </sources>
    <trace autoflush="true" />
</system.diagnostics>

Donde evidentemente estamos indicando dónde se almacenará el log que podremos ir consultando. Por último, sólo falta indicarle a las clases de los servicios que queremos incluirlos en el sistema de logging especificándole el comportamiento IncludeExpcetionDetailInFaults en la cabecera de la clase:

   1: [ServiceBehavior(IncludeExceptionDetailInFaults= true)]

   2: public class Service

   3: {

   4: ...

   5: }

Ahora, cada vez que se produzca un fallo podemos verlo en el fichero WcfMessage que hemos especificado para ver exactamente que es lo que está ocurriendo por debajo y así poder facilitar las tareas de depuración.

[VS2010] IntelliTrace ( II )

IntellITrace también ofrece un soporte avanzado para aquellas situaciones en las que todo desarrollador sufre alguna vez en la vida. Supongamos el siguiente escenario, donde nuestra aplicación produce un fallo que no ha sido detectado y procedemos a debuggear el código…pero no logramos localizar el fallo. En ese caso podemos emplear la característica de IntelliTrace de guardar una captura de debug. Para ello lo primero que debemos hacer es indicarle que deseamos guardar la traza:

Una vez hecho esto, prestemos especial atención a la casilla de Team Foundation Server. Esto permitirá que Team Foundation Server (TFS) recoja mediante el TestManager las capturas de debug y las envíe a los tester mientras el desarrollo continúa. En estas capturas no es sólo un volcado común de pila, sino es un conjunto de estados en los que la aplicación ha ido alterando a lo largo del tiempo. De este modo podremos ver los eventos y llamadas en cualquier momento anterior al presente, como se expuso en el primer artículo.

El siguiente paso es abrir el fichero .itrace. Al abrirlo, podemos apreciar una captura como la que sigue a continuación del siguiente párrafo:

Podemos expandir los campos para ver la información de hilos, excepciones, módulos y datos de testing. Al hacer clic sobre un hilo se cargan todos los eventos ocurridos y si por ejemplo, hacemos clic en cualquier elemento (como una excepción) automáticamente nos llevará al estado en el que se produjo, y ya podremos navegar por IntelliTrace al igual que se mostró en el primer artículo.

Por último resalto la posibilidad de aplicar extensiones a IntelliTrace. A través de MSDN obtenemos toda la información necesaria del API para analizar la recolección de datos y aquí podemos obtener algunos ejemplos prácticos.