Reportes Agiles en Team Foundation Server – Build Quality Indicators Report

por Viviana Chelini  28. septiembre 2010

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Seguimos en este post con:

 

Build Quality Indicators Report

El siguiente reporte muestra la cobertura de pruebas, la renovación de código y el número de errores para una compilación especificada.

 

Información que proporciona el reporte

En el reporte se puede visualizar sobre el eje X las compilaciones que incluye el reporte, sobre la base de los filtros establecidos para la plataforma, la configuración y la definición de la compilación.

Cada barra vertical representa un conjunto de datos derivados de una o más compilaciones. En la variante de tamaño de código del reporte, la longitud de cada barra vertical representa el tamaño de la base de código protegida. Las pruebas manuales se pueden ejecutar en cualquier momento después de la compilación y están asociadas a esa compilación. Las pruebas que no se han ejecutado todavía se cuentan como "no concluyentes".

En la siguiente tabla se describe la información que aparece en el reporte:

Indicador

Descripción

Errores activos (número)

Gráfico de líneas que representa el número de errores que estaban activos al momento de la compilación.

Renovación de código (líneas)

Gráfico de líneas que describe el número de líneas de código que el equipo agregó, quitó y modificó antes de la compilación. La renovación de código se calcula determinando el número de líneas de código que se han agregado, eliminado o modificado en la compilación dividido por el número total de líneas de la compilación.

Cobertura de código (porcentaje)

Gráfico de líneas que representa el porcentaje de código que cubren las pruebas.

Pruebas no concluyentes

Gráfico de barras apiladas de color gris que indica el número de pruebas que no tuvieron un resultado correcto o se pusieron en pausa. Si la compilación no tuvo un resultado correcto, las pruebas no se cuentan o se cuentan como no concluyentes.

Ejemplo de informe Indicadores de calidad de la compilación

Pruebas no superadas

Gráfico de barras apiladas de color rojo que indica el número de pruebas no superadas para la compilación.

Pruebas superadas

Gráfico de barras apiladas de color verde que indica el número de pruebas superadas para la compilación.

Para que el reporte sea fiable los miembros del equipo deben realizar las siguientes actividades para administrar pruebas y compilaciones:

  • Configurar un sistema de compilación. Para utilizar Team Foundation Build, debe configurar un sistema de compilación.
  • Crear definiciones de compilación. Puede crear varias definiciones de compilación, de modo que cada una de ellas pueda ejecutarse para generar código para una plataforma diferente.
  • Definir las pruebas que se ejecutarán automáticamente como parte de la compilación.
  • Configurar las pruebas para recopilar datos de cobertura de código. Para que los datos de cobertura de código aparezcan en el reporte, los miembros del equipo deben instrumentar las pruebas para recopilar esos datos.
  • Ejecutar compilaciones con regularidad. Puede ejecutar compilaciones a intervalos establecidos o después de cada protección. Puede crear compilaciones periódicas cuando utilice el desencadenador de programación.

 

Análisis del reporte

El reporte permite responder las siguientes preguntas:

  • ¿Cuál es la calidad del software?
  • ¿Está el equipo probando suficiente código?
  • ¿Se están superando las pruebas?
  • ¿Es probable que el equipo termine en función del código y las métricas de pruebas?
  • ¿Con qué frecuencia se superan las pruebas y con qué frecuencia se prueba el código?

 

Versión positiva del reporte

Un reporte positivo muestra los siguientes indicadores:

  • La mayoría de las pruebas se superan (áreas grandes de color verde) y pocas pruebas no se superan (cantidades pequeñas de color rojo).
  • El porcentaje de color rojo es inferior al 20-30 por ciento.

Versión positiva del indicador de calidades de compilación

 

Versiones negativas del reporte

Una versión negativa mostrará uno o más de los siguientes indicadores:

  • Menos cobertura de código y más renovación de código. Podría indicar que el nuevo código se protege sin las correspondientes pruebas unitarias que lo cubran.

    Renovación de código del informe Indicadores de calidad de la compilación

  • Baja tasa de pruebas en ejecución. Estos datos podrían indicar que el equipo no está realizando suficientes pruebas. Este bloqueo podría indicar falta de recursos o que los evaluadores estén haciendo otras tareas, como escribir la automatización de pruebas en lugar de probar la funcionalidad actual.

    Baja tasa de pruebas en el informe Indicadores de calidad de la compilación

  • Alta renovación de código, baja tasa de cobertura de código. Una alta renovación de código sugiere que los errores se introducirán como efectos secundarios de los cambios. De lo contrario, una alta renovación de código podría indicar una cobertura reducida y la necesidad de reescribir pruebas.

    Alta renovación de código en el informe Indicadores de calidad de la compilación

  • Tasa alta de pruebas no superadas. La siguiente ilustración muestra que muchas pruebas se realizan con una cobertura de código razonable, pero que no se están superando las pruebas. Estos datos podrían indicar prácticas de desarrollo poco rigurosas o, en iteraciones tempranas, que las pruebas son demasiado duras para esta etapa del producto.

    Prueba no superada en el informe Indicadores de calidad de la compilación

  • Alta tasa de pruebas que se superan y alta tasa de errores activos. La siguiente ilustración muestra una alta tasa de pruebas superadas pero, no obstante, un alta tasa de errores de entrada. Esta situación se puede producir por varias razones. Es posible que las pruebas no sean suficientemente rigurosas para esta etapa del producto.

    Baja tasa de pruebas en el informe Indicadores de calidad de la compilación

  • Tasa creciente de superación de pruebas sin aumento en la cobertura de código. Habitualmente, cuantas más pruebas se realizan, se debe cubrir más código. Por otro lado, si la ejecución de pruebas y las tasas de superación de pruebas aumentan sin un aumento correspondiente en la cobertura de código, es posible que las pruebas incrementales sean redundantes.
  • El número de errores activos aumenta, pero las pruebas no superadas no aumentan. Es probable que las pruebas no estén probando la misma funcionalidad que indican los errores.
  • El número de errores activos está disminuyendo, pero las pruebas superadas no aumentan. Puede que exista un aumento en la tasa de reactivación.

 

 

Tags: , ,

ALM | Gestión de Proyectos | TFS

Reportes Agiles en Team Foundation Server – Reactivation Report

por Viviana Chelini  24. septiembre 2010

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Seguimos en este post con:

 

Reactivation Report

A medida que el equipo resuelve y cierra los errores, se puede utilizar el reporte de Reactivaciones para determinar la eficacia con que el equipo corrige los errores.

Las reactivaciones se refirieren a errores que se han resuelto o cerrado tempranamente y, a continuación, se han vuelto a abrir. La tasa de la reactivación también se la denomina tasa de retorno de errores.

Este reporte se puede utilizar para mostrar los errores y casos de uso que se han reactivado. Una tasa de reactivaciones baja (por ejemplo, menor que el 5%) podría ser aceptable dependiendo de los objetivos del equipo. Sin embargo, una tasa alto o creciente de reactivaciones indica que el equipo podría necesitar diagnosticar y corregir otros problemas.

Información que proporciona el reporte

El reporte de Reactivaciones informa en un gráfico de superficie el número de errores o casos que se han resuelto o reactivado después de cerrarlos.

 

Reactivation Report

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:

  • Definir casos de uso y errores, y especificar sus rutas de iteración y de área.
  • Actualizar el Estado de los casos y errores a medida que avanzan desde que se activan hasta que se cierran.

 

Análisis del reporte

Es normal que el reporte varíe según el punto del ciclo de desarrollo del producto en que nos encontremos. Las iteraciones tempranas deberían presentar muy pocas reactivaciones.

El reporte de Reactivaciones muestra información que se puede utilizar para detectar si el equipo está reactivando un número alto de errores o casos, esta tasa se obtiene de contar el número de errores supuestamente corregidos cuyas correcciones no funcionan. Estas reactivaciones pueden crear un ciclo de repetición del trabajo que interfiere con las tareas planeadas.

El reporte permite responder las siguientes preguntas:

  • ¿Cuántos errores se han reactivado en la iteración actual?
  • ¿Cuántos casos de uso se han reactivado en la iteración actual?
  • ¿El equipo está resolviendo y cerrando los errores y casos reactivados a una velocidad aceptable?

 

Versión positiva del reporte

Una versión positiva del reporte muestra un progreso sostenido de resolución y cierre de errores. La tasa total de reactivación de elementos de trabajo es del 5% o inferior, y no aumenta durante la iteración. Cuanto menor sea la tasa de reactivación, más podrá progresar el equipo en su conjunto.

Versión Positiva - Reactivaction Report

 

Versión negativa del reporte

 

Versión Negativa - Reactivaction Report

Una versión negativa del reporte podría indicar:

El equipo está reactivando una cantidad elevada de errores. Una tasa de reactivación de errores alta podría indicar que el equipo está cerrando los errores rápidamente. Este indicador se podría tomar como una mala señal para el proyecto, ya que las reactivaciones introducen trabajo adicional que duplica el esfuerzo total que se necesita para completar el trabajo correspondiente.

El equipo está reactivando un número alto de casos de uso La tasa de reactivación de casos de uso debe considerarse como un porcentaje del número total de casos de uso que el equipo está cerrando.

 

Tags: , , ,

ALM | Gestión de Proyectos | TFS

WCF TIPS - Como generar una descarga http estándar y hostearla desde un servicio

por maxi  20. septiembre 2010

    Objectivo: Crear un ejemplo de servicio con WCF que permita a un navegador descargar un archivo por http en forma estándar.

    Características del servicio:

    • Self-Host: En este caso va a ser Self-host  en una aplicacion Winforms asi puede ser hosteado en cualquier maquina sin necesidad de configurar un IIS.

    • REST: No se utilizara SOA, ya que REST es más liviano dado que el mensaje no tiene toda la información del Envelope SOAP.

      Streamming: El servicio enviará el archivo en mediante Streamming lo que permite manejar archivos grandes.

    • Multithreading: el servicio no será Single es decir una instancia del servicio atenderá cada llamada, de esta forma el servicio no encolara las solicitudes si no que podrá atender varias descargas al mismo tiempo y a diferentes clientes.

      Lo primero que haremos será crear el contrato, al que llame IDownloadService que contiene el método DownloadFileHttp, el cual recibe el path y el nombre del archivo para descargar y retornara el Stream.

      Esta claro que no es ideal recibir el path del archivo en el servicio, pero lo hice para ejemplificar como recibir varios parametros ya que este servicio utiliza REST por lo cual el servicio recibe los parametros en forma de query string. El atributo WebGet precisamente nos permite definir que el servicio recibira la solicitud mediante una url de la siguiente forma:

                                       DirecciónBase           / download    / path / fileName

      P.e.: http://localhost:9000/DownloadService / download    / C:@mp3  /   tema.mp3

       
           [ServiceContract]
          public interface IDownloadService
          {
              [OperationContract]
              [WebGet(UriTemplate = "download/{path}/{fileName}")]
              Stream DownloadFileHttp(string path, string fileName);
          }
       

      Una vez definido el contrato vamos  a implementarlo de la siguiente manera:

       
        [ServiceBehavior(
              //Cada solicitud crea una nueva instancia de StreamerSvc y se recicla despeus de la llamada 
              //De esta forma las llamadas no se encolan se puede atender a varios clientes
              InstanceContextMode = InstanceContextMode.PerCall,
              //La instancia del servicio es multi threaded
              //Los threads pueden llamar a cualquier operacion del servicio en cualquier momento
              //Multiple implica que le programador tiene que manejar la sincronizacion con locks
              //Pero como el servicio no maneja estados, p.e. variables o atributo de clase no me afecta
              ConcurrencyMode = ConcurrencyMode.Multiple,
              //Esta propiedad hay que setearla en este ejemplo ya que el servicio esta siendo hosteado en una aplicacon Winforms
              //Implica que todas las llamadas al servicio correran en el mismo thread de la UI que creo el servicio (new ServiceHost(...)))
              //La pongo en false para evitar deadlocks ya que por defecto es true
              UseSynchronizationContext = false)]    public class DownloadSvc : IDownloadStream
          {
              public Stream DownloadFileHttp(string path, string fileName)
              {
      //Truco para poder poner el path en la url solo para este ejemplo
                      path = path.Replace("@", @"\");@", @"\");File does not exists!");application/download";content-disposition", string.Format("attachment;filename=\"{0}\"", fileName));
                      fileName = fileName.Replace("
                      path = Path.Combine(path, fileName);
       
                      if (!File.Exists(path))
                      {
                          throw new FaultException("
                      }
              
                      //Abrimos el archivo 
                      var fileStream = File.OpenRead(path);
       
                      //Configurar Headers para el cliente p.e. un browser
                      var headers = WebOperationContext.Current.OutgoingResponse.Headers;
                      WebOperationContext.Current.OutgoingResponse.ContentType = "
                      headers.Add("
                      headers.Add("content-length", fileStream.Length.ToString());
       
               //Retonranos FileStream
                      return fileStream;
              }}
        

      Muy bonito pero para que todo esto funcione correctamente debemos configurar nuestro servicio. Para esto vamos a setear las siguientes entradas en el config:

       
      <?xml version="1.0" encoding="utf-8"?>
      <configuration>
               <system.serviceModel>
                         <bindings>
                                  <mexHttpBinding>
                                            <binding name="MetadataBinding" />
                                  </mexHttpBinding>
                                  <webHttpBinding>
                                            <binding name="DownloadBinding" sendTimeout="00:10:00" maxBufferPoolSize="2147483647"
                                             maxReceivedMessageSize="2147483647" transferMode="Streamed">
                                            </binding>
                                  </webHttpBinding>
                         </bindings>
                         <services>
                                  <service behaviorConfiguration="ServiceBehavior" name="StreamerSvcHost.StreamerSvc">                             
                                            <endpoint address="mex" binding="mexHttpBinding" bindingConfiguration="MetadataBinding"
                                             name="MetadataEndpoint" contract="IMetadataExchange" />
                                            <endpoint address="FileSvc" behaviorConfiguration="RestBehavior"
                                             binding="webHttpBinding" bindingConfiguration="DownloadBinding"
                                             name="DownloadEndpoint" contract="StreamerSvcHost.IDownloadService" />
                                            <host>
                                                     <baseAddresses>
                                                              <add baseAddress="http://localhost:9000/" />
                                                     </baseAddresses>
                                            </host>
                                  </service>
                         </services>
                         <behaviors>
                                  <endpointBehaviors>
                                            <behavior name="RestBehavior">
                                                     <webHttp />
                                            </behavior>
                                  </endpointBehaviors>
                                  <serviceBehaviors>
                                            <behavior name="ServiceBehavior">
                                                     <serviceMetadata httpGetEnabled="true" />
                                                     <serviceDebug includeExceptionDetailInFaults="true" />
                                                     <dataContractSerializer maxItemsInObjectGraph="2147483647" />
                                            </behavior>
                                  </serviceBehaviors>
                         </behaviors>
               </system.serviceModel>

      </configuration>

       

        Lo destacable es lo siguiente:

        • El endpoint deberá tener un webHttpBinding, esto permite exponer el servicio para ser accedido mediante HTTP requests  en lugar de mensajes SOAP.

        • El binding se deberá configurar con TransferMode = Streamed

        • El endpoint deberá tener configura un EndpointBehavior agregándole le elemento webHttp, para que un cliente pueda comunicarse por http con el servicio este debe tener asociado este comportamiento.

        Tags: , , , , , ,

        WCF

        Reportes Agiles en Team Foundation Server – Bug Trend Report

        por Viviana Chelini  16. septiembre 2010

        En el post anterior publiqué una introducción al tema de reportes Ágiles y un resumen de uno de los reportes.

        Seguimos la serie con:

        Bug Trend Report

        El siguiente reporte ayuda a obtener y seguir la tasa de detección y resolución de errores del equipo. Este reporte muestra un promedio acumulado o móvil de los errores notificados, resueltos y cerrados a lo largo del tiempo, obteniendo una visión de la medida en que el equipo está encontrando, resolviendo y cerrando los errores.

        Información que proporciona el reporte

        El reporte calcula un promedio acumulado del número de errores que el equipo ha abierto, resuelto y cerrado. El promedio acumulado se basa en los siete días antes de la fecha para la que se calcula. Es decir, el reporte calcula el promedio del número de errores en cada estado para cada uno de los siete días antes de la fecha y, a continuación, divide el resultado entre siete.

        BugStatusReport1

         

        Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:

        • Definir los errores y especificar sus rutas de acceso de Área e Iteración.
        • Actualizar el Estado de cada error cuando se ha corregido, probado y cerrado.
        • Especificar la Prioridad y Gravedad de cada error durante la evaluación de errores.


        Análisis del reporte

        Las tasas de errores se interpretan mejor comparándolas con todas las actividades de proyecto de equipo actuales y las otras métricas que proporcionan los reportes de Estado del error y Reactivaciones. Por ejemplo, el equipo podría encontrar errores con especial rapidez en código mal escrito, en código recientemente integrado, con pruebas mejoradas o durante un evento excepcional como una búsqueda intensiva de errores. Por otra parte, los errores son más difíciles de encontrar en un producto de alta calidad y con pruebas ineficaces. Cuando el producto se estabiliza hacia el fin de un ciclo del producto, el equipo debería encontrar errores con menos frecuencia.

        El reporte podría informar determinadas situaciones que se deberían evaluar porque surgen:

        · El equipo encuentra el mismo número de errores aproximadamente en períodos de tiempo sucesivos.

        o ¿Son adecuados los casos de prueba para probar los casos de uso que se están desarrollando?

        o ¿Las pruebas se han vuelto obsoletas o están probando la funcionalidad equivocada?

        o ¿El equipo de pruebas está probando cada caso de uso rigurosamente?

        · El equipo resuelve muchos errores en cada período

        o ¿Se cierran rápidamente los errores resueltos? La tasa de errores cerrados debe ser similar a la de errores resueltos.

        o ¿Permanecen las reactivaciones de errores dentro de los límites esperados?

        · El equipo resuelve los errores rápidamente pero no los cierra.

        o ¿Están sobreasignados los recursos de pruebas?

        o ¿Debería el equipo volver a revisar las prioridades de pruebas?

        Versión positiva del reporte

        Un reporte positivo muestra que el equipo encuentra más errores en el inicio de un ciclo de desarrollo y menos errores hacia el fin de una iteración. Cuando el equipo resuelve los errores más rápidamente que los encuentra, el número de errores activos empezará a disminuir. Cuando el equipo empieza a encontrar menos errores, el producto se estará estabilizando.

        Versión negativa del reporte

        Un reporte negativo podría mostrar que el equipo encuentra errores más rápidamente a medida que se acerca la fecha de envío y los resuelve más lentamente. En esta situación, el trabajo pendiente del equipo está aumentando, ya que los errores no se corrigen y sería conveniente investigar las causas.

         

         

        BugStatusReport2

        Reportes Agiles en Team Foundation Server – Introducción y Bug Status Report

        por Viviana Chelini  16. septiembre 2010

         

        Introducción

        Cuando la empresa entró en un nuevo camino de cambio orientado a las metodologías agiles y todo lo que ello implica, nos pusimos a investigar con una colega cómo hacer para poder implementar esta metodología en el ambiente de trabajo cotidiano sin que esto afectara fuertemente el ritmo laboral actual.

        Nuestra primera intención fue mejorar la forma en que encarábamos una iteración, teniendo un control de las horas y tareas realizadas por parte del equipo y también la forma en que organizábamos nuestro trabajo en el TFS, para ello queríamos determinar cuál era la velocidad de nuestro equipo, cuánto trabajo restaba realizar, si el tiempo restante en la iteración era suficiente para completar las tareas planificadas, si la cantidad de casos de prueba realizados eran suficientes, etc.

        Investigando nos encontramos con los nuevos reportes que ofrece el nuevo Template de Agile, los cuales contestaban cada una de nuestras preguntas. Nos interiorizamos en el tema para saber que datos requería y que información devolvía, porque si ello no los íbamos a poder implementar adecuadamente.

        El pequeño estudio que realizamos fue sobre la propia página de Microsoft MSDN en la cual se encuentra explicado de forma muy completa el nuevo Template y también cada uno de los reportes que ofrece.

        http://msdn.microsoft.com/en-us/library/dd380714.aspx

        Se tomó cada uno de los reportes y se realizó un breve resumen de cada uno de ellos definiendo cual es la información de devuelve el mismo, que parámetros de los elementos de trabajos se deben de alimentar, un análisis del reporte considerando a que pregunta podría llegar a responder el informe, como así también una versión positiva y negativa del reporte.

        Esto no es más que una recopilación de cada uno de ellos considerando únicamente la información que nos era relevante. Espero que les sea de ayuda y puedan implementar estas herramientas que ofrece actualmente el TFS y muy pocas personas conocen de su existencia.

         

        Bug Status Report

        Este reporte muestra el número de errores acumulado basado en el estado del error, la prioridad y la gravedad. (state, priority, and severity).

        Información que proporciona el reporte

        BugStatusReport1

         

        BugStatusReport2

        · Número de errores: Representa el número de errores acumulados, agrupados según el estado en el cual se encuentran.

        · Errores activos por prioridad/gravedad : Gráfico circular que muestra el número de errores que se encuentran activos, agrupados por prioridad o gravedad.

        · Errores activos por asignación: Gráfico de barras horizontales con el número total de errores activos que cada miembro del equipo tiene asignados actualmente, agrupados por prioridad o gravedad.

        · Errores resueltos por asignación: Gráfico de barras horizontales con el número total de errores resueltos que cada miembro del equipo tiene asignados, agrupados por prioridad o gravedad.

        Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:

        • Definir los errores y especificar sus rutas de acceso de Área e Iteración.
        • Especificar la Prioridad y Gravedad de cada error.
        • Asignar a cada error un miembro del equipo dedicado a resolverlo o cerrarlo.
        • Actualizar el estado de cada error cuando se ha corregido, probado y cerrado.

         

        Análisis del reporte

        El reporte varía según el punto del ciclo de desarrollo del producto. Las iteraciones tempranas deben mostrar un aumento gradual del número de errores activos. Las iteraciones que están cercanas al final de un ciclo de desarrollo deben mostrar un amplio número de errores resueltos. El mismo permite responder a las siguientes preguntas:

        • ¿Con qué rapidez resuelve y cierra errores el equipo?
        • ¿El equipo corrige los errores con la rapidez suficiente para finalizar a tiempo?
        • ¿El equipo corrige primero los errores de alta prioridad?
        • ¿Cómo se distribuyen los errores por prioridad y gravedad?
        • ¿Cuántos errores hay asignados a cada miembro del equipo?
        • ¿Algún miembro del equipo necesita ayuda para resolver o cerrar errores?

         

        Versión positiva del reporte

        La versión positiva del reporte muestra un aumento de los errores activos a medida que pasa el tiempo seguido de una resolución y cierre de errores.

        BugStatusReport3 

         

        Versión negativa del reporte

        Un reporte negativo muestra uno o más de los indicadores que se describen en la siguiente tabla:

        BugStatusReport4

        · Se amplía la cantidad de errores activos. Si se amplía la cantidad de errores activos del equipo, eso significa que aumenta el trabajo pendiente de errores. El equipo detecta más errores de los que puede resolver o cerrar. Según esto podríamos determinar que la cantidad de errores a crecido potencialmente debido a diferentes problemas: problema en el equipo para resolver y cerrar errores o su capacidad se ve demorada por asuntos externos.

        · La cantidad de errores activos no cambia. Una tendencia constante en el número de errores activos indica que el equipo no detecta errores, esto se puede deber a un problema en las pruebas o el equipo está teniendo dificultades para crearlo.

        · La cantidad de errores resueltos o cerrados no cambia. Cuando la cantidad de errores resueltos o cerrados por el equipo no cambia durante un período de tiempo prolongado, es posible que los miembros del equipo no sean capaces de resolver o cerrar esos errores. Ante este indicador uno se puede plantear diferentes situaciones: el equipo está destinado en el tiempo asignado a resolver las tareas, se definieron correctamente las tareas que debía de realizar o se debería de validar si el equipo está alimentando correctamente los estados de los errores.

        · Las asignaciones de errores no están distribuidas de manera uniforme. Se debe de realizar una reasignación de errores si es que el equipo no se encuentra equilibrado con respecto a los errores que tiene asignados.


        Seguimos en próximos artículos explicando otros reportes ágiles.

        Tags: , ,

        ALM | Metodologías y Procesos | TFS

        WCF Tips - Clases definidas en el servicio que no aparecen en el proxy del cliente?

        por maxi  14. septiembre 2010

        Cuando generamos una referencia a un servicio en un proyecto de Visual Studio se genera un proxy con todos los métodos definidos en el ServiceContract y las clases definidas como DataContract.
        Los DataContract aparecen en el proxy cuando son recibidos o retornados por algún método de la interfaz. En caso contrario no se generará ya que no aparece en la metadata del servicio.

        Si por algun caso en particular, nosotros utilizamos alguna clase o un enum en un proceso del servicio y este no es recibido ni retornado por ningun metodo y quisieramos utilizarlo del lado, es decir en el cliente,
        estaríamos obligados a duplicarlos manualmente. Por lo tanto vamos a querer que se generen en el proxy del cliente y para lograr esto debemos hacer lo siguiente:

        Primero, generamos una clase que va a contener un método que retornará la lista de clases que serán agregadas a la metadata del servicio. Luego implementamos el método correspoindiente el cual debe retornar una lista de Types, IEnumerable<Type>, y recibirá como parametro un ICustomAttributeProvider. Internamente creamos una lista donde agregamos los Type deseados como se muestra a continuación:

         

         

         

           1:      public static class EnumHelper
           2:      {
           3:          /// <summary>
           4:          /// Obtiene una lista de tipos conocidos que se requieren publicar al cliente
           5:          /// </summary>
           6:          /// <param name="provider"></param>
           7:          /// <returns></returns>
           8:          public static IEnumerable<Type> ObtenerTiposConocidos(ICustomAttributeProvider provider)
           9:          {
          10:              //Incluir los tipos que se requiere ver en el cliente
          11:              var tiposConocidos = new List<Type>
          12:                                              {
          13:                                                  typeof (CodigosMovEnum),
          14:                                                  typeof (Etc)
          15:                                              };
          16:   
          17:              return tiposConocidos;
          18:          }
          19:      }


         

        Segundo, debemos agregar el Atributo ServiceKnownType a nuestro contrato de servicio. Y vamos a pasar como parámetros, primero el Metodo que retorna los Types de las clases que serán agregadas

        en la metadata del servicio y luego, el Type de la clase que contiene dicho método que en este caso es EnumHelper como se muestra a continuación:

         

           1:      [ServiceKnownType("ObtenerTiposConocidos", typeof(EnumHelper))]
           2:      [ServiceContract]
           3:      public partial interface IMiServiceContract
           4:     {    
           5:     }

         

        Luego compilamos el servicio y al actualizar la referencia al proxy del cliente apareceran estas nuevas clases.

         

        Tags: ,

        WCF Tips - Enum definirlo en el servicio y utilizarlo en el cliente

        por maxi  14. septiembre 2010

        Para utilizar un enum simplemente lo definimos y agregamos el atributo DataContract. A cada valor del enum le definimos el atributo EnumMember.

        De esta forma si este enum se recibe como parámetro o es retornado por un metodo del servicio, se generará en la referencia al servicio del cliente.

         

            [DataContract]
        public enum CodigosMovEnum
        {
        [EnumMember]
        Ninguno = 0,

        [EnumMember]
        AEntregar = 1,

        [EnumMember]
        ACumplir = 2,

        }

        Tags: ,

        WCF

        Acerca de los Autores

        Este es el blog del equipo de VEMN SA 
        Presentaremos temas que nos parezcan de interés sobre tecnología .NET, Procesos y Metodologías y todo aquello relacionado con el proceso de desarrollo de Software

        Month List

        BlogRoll

        Download OPML file OPML