Grupo Solutio realiza la formación oficial en tecnologías Microsoft en la Universidad Politécnica de Madrid

Desde Grupo Solutio estamos realizando una formación en la Ingeniería de Informática de la Universidad Politécnica de Madrid, que permitirá a los alumnos obtener hasta 3 créditos de la carrera, con temas tan interesantes como Xamarin, .NET Core y Azure.

Estamos super orgullosos de ser el partner de Microsoft que prepara a los alumnos que en un futuro serán preescriptores de tecnlogía Microsoft en sus empresas y nos permitirán a todos seguir disfrutando de estas comunidades como geeks.ms que tanto nos gustan.

Este es el cartel del primer cuatrimestre:

UPM - Cartel ETSISI V2

 

Entity Framework. Entidades con grafos complejos

Hola

     Si tenéis un rato estaría bien que si podéis dediquéis un minuto a votar en el link de esta página, logados con vuestra cuenta msn.

     Con los votos se está pidiendo que el equipo de producto de Entity Framework desarrolle el soporte para la persistencia de entidades con grafos complejos en el caso de sistemas desconectados.

      Es algo importante que es esencial para el desarrollo de aplicaciones n-layered.

    https://entityframework.codeplex.com/workitem/864

gracias

Integración Continua con Microsoft Visual Studio Team Foundation Server 2010 y Microsoft Web Deploy

 

Pues después de unos cuantos años haciendo builds, IC y demás os paso a poner un pequeño post para que los que estéis empezando con estos temas os resulte más fácil.

Primero creo que es importante hacer una pequeña referencia a lo que es Integración Continua.

Levels of Code Confidence

Antes de entrar en lo que es IC deberíamos tener claros los niveles de confianza del código, mejor lo ponemos en inglés que queda mejor. Levels of Code Confidence

• Primer nivel de Confianza. ¿Compila el código?. Si el código compila podemos asegurar que sintácticamente esta correctamente escrito, pero no podemos garantizar el fallo en ejecución.

• Segundo nivel de confianza. ¿Pasa el código nuestros Test?. Si nuestros test unitarios se ejecutan correctamente, habremos superado el segundo nivel de confianza.

• Tercer nivel de confianza. ¿Cubre el código nuestros requerimientos de negocio?. Si nuestras pruebas de usuario se ejecutan correctamente, habremos superado el tercer nivel de confianza.

• Cuarto nivel de confianza. ¿Cubre el código nuestros requerimientos de calidad?. Si se cubren nuestras métricas de código en cuanto a complejidad, habremos superado el cuarto nivel de confianza.

Integración Continua y sus Beneficios.

Entonces ¿Qué sería la Integración Continua?

La integración continua es un proceso que nos ayuda a cumplir con los niveles de confianza del código de una manera automatizada y entre otros nos aporta los siguientes beneficios.

• El código que hay en nuestro sistema de control de código “Funciona”. El código funciona a un determinado nivel: compila, pasa nuestros test unitarios, satisface nuestras métricas de código, etc.

• Menor tiempo invertido en integración. Permite la integración de los distintos componentes de un sistema de una manera más rápida y su evaluación de que funcionan correctamente y conjuntamente.

• Incrementa la visibilidad del proceso. Podemos ver el progreso de una manera más rápida, ya que cualquiera puede acceder a la versión actual desplegada mediante la IC y validar que lo que está 100% finalizado, realmente lo está.

• Reduce el riesgo del proyecto. Debido a este incremento de visibilidad del avance, se reduce el riesgo del proyecto.

• Reduce la fricción dentro de los equipos de proyecto. No hay que acceder al equipo para obtener una versión de software, la versión de Software estará siempre disponible.

• Incrementa la autonomía de los Testers. Disponen de los últimos avances desarrollados disponibles para probar.

• Menor tiempo invertido en la creación y despliegue de versiones. La automatización de la creación y despliegue de versiones, hace que todo este trabajo repetitivo sea considerado como una reducción notable de tiempo que no empleará el equipo.

• Incrementa la confianza entre los usuarios de negocio y el equipo de proyecto.

Integración Continua. Build de IC.

Sería difícil implementar IC sin disponer de una automatización de Builds que nos permita hacer de manera repetitiva algo que sino tendríamos que hacer de manera manual.

Para esto podemos utilizar Team Foundation Server. En realidad en una IC deberíamos pasar por todos estos niveles

image

Como esto es un pequeño ejemplillo, pues digamos que vamos a ver un proyecto que compila, se ejecutan los test, se crea el paquete de instalación y se despliega automáticamente en el entorno de test.

Los requisitos para este ejemplo son:

En el lado del servidor:

  • Windows Server 2008 r2
  • Team Foundation Server 2010 y Team Foundation Server Build
  • Microsoft Web Deploy + todo lo que requiera por debajo en su instalación.

En el lado del cliente:

  • Visual Studio 2010
  • La solución ejemplo por ejemplo de MVC que ofrece el Visual Studio.

Se pueden hacer múltiples escenarios de deploy en el que tengamos que hacer cosas muy diferentes, yo he pasado por utilizar scripts, crear custom activities de WF para modificar los Templates de las Build de TFS, etc. Pero para este ejemplo he utilizado algo rápido y fácil de entender como webdeploy.

Sobre la solución original que crea Visual Studio, he añadido 3 transformaciones de ficheros web.config, para los típicos debug y release, así como un entorno personalizado que he llamado TestEnv.

image

En el Web.config principal he añadido una entrada en el Appsetings que sirve para almacenar el entorno en el que se “ejecuta” la aplicación.

image

En el caso de cada Web config transformado, se añade la conversión y el valor necesario para transformar el valor para el entorno en concreto.

image

También he modificado el controller del home para visualizar el valor de la variable del appconfig una vez que se ha desplegado, así podemos ver si se muestra el correcto, es decir si se ha producido la transformación de valores orientados para cada entorno, como pueden ser cadenas de conexión, etc.

En nuestro caso sólo la variable entorno.

image

Sí ejecutáramos en local, veríamos que aparece el literal “Entorno de desarrollo” y la versión 1.0 que es lo que tenemos puesto a pelo para empezar en el código de la vista.

image

Para preparar el servidor web, desplegamos a mano creando el sitio en el servidor de despliegue de pruebas, desplegando la misma versión y probamos que funcione.

Una vez que tenemos nuestra solución preparada, pues creamos la Build. Yo por norma suelo poner la rama y alguna información más como las siglas IC para saber que no es una build manual.

image

Después configuramos la build como build de integración continua.

image

Indicamos la carpeta base de los fuentes, etc

image

Especificamos la salida del Drop de la compilación.

image

Indicamos la solución a construir con la configuración que queramos, Release, Debug u otra que hayamos creado nosotros personalizada.

image

Lanzamos la build.

image

Y veremos si funciona.

image

Una vez que hemos probado la build, podemos pasar a indicarle los parámetros que forzarán a WebDeploy a desplegar nuestra aplicación.

/p:DeployOnBuild=True;

DeployTarget=MsDeployPublish;

CreatePackageOnPublish=False;

MSDeployPublishMethod=RemoteAgent;

AllowUntrustedCertificate=True;

MSDeployServiceUrl=MaquinadeDespliegue;

DeployIisAppPath=»Aplicación Web de despliegue»;

UserName=UsuarioDespliegue;

Password=ContraseñaUsuario

image

Una vez que hemos modificado la build, podemos cambiar el código de la vista home para que muestre por ejemplo 2.0 en el texto.

image

Creamos el Task (ya sabéis nada de subir las cosas de cualquier manera) y chacemos Checkin

image

Automáticamente se ejecuta la build de IC

image

Si ha pasado los Test, etc. La tendremos marcada como OK

image

Y si miramos lo que hay ahora en el servidor, veremos que se ha desplegado, que además nos pone “entorno debug” correspondiente con el tipo de compilación que elegimos (en mi caso debug).

image

 

En resumen, por cada checkin podríamos tener una compilación y una versión desplegada en un entorno de pruebas para probar.

Está claro que esto es un mundo, pero bueno los que queráis podéis empezar por aquí.

The Dependency Inversion Principle

Hoy escribo para poner uno de los artículos más curiosos, que por el añ0 1996 publicaba Bob Martin en su C++ report, que ha sido la base para cosas como Unity o Castle Windsor.

En aquellos tiempos en que algunos empezábamos a pegarnos con Visual Basic 3, 4, etc., había gente que sentaba las bases de algo que ahora utilizamos tanto.

Pues nada, el artículo original está aquí, que lo disfrutéis:

 

http://www.objectmentor.com/resources/articles/dip.pdf

 

Maximum number of items that can be serialized or deserialized in an object graph is 65536. Change the object graph or increase the MaxItemsInObjectGraph quota.

 

Cuando nos aparece este error la solución es sencilla y pasa por ampliar el número de objetos que el Serializer utilizado en WCF pueda serializar.

Esta configuración se debe realizar en el apartado behavior.

El problema surge cuando el cliente que tenemos es una aplicación silverlight. ¿Por qué? pues porque en un .config de silverlight no podemos incluir el behavior.

La solución pese a poder parecer compleja, puesto que ambos extremos, cliente y servidor deben ser idénticos, es realmente sencilla.

Basta con configurar el behavior solo en el servidor y el cliente silverlight funcionará perfectamente.

Así, con añadir un behavior  en el web config del lado del servidor como el sliguiente

Code Snippet
  1. <behavior name=«CustomEndPointBehavior«>
  2.   <dataContractSerializer maxItemsInObjectGraph=«2147483647« />
  3. </behavior>

           Y referenciarlo en el el endpoint del servicio en el web.config del lado del servidor

Code Snippet
  1. <endpoint
  2.   address=«»
  3.   binding=«basicHttpBinding«
  4.   bindingConfiguration=«BindignConf«
  5.   name=«Binding_name«
  6.   contract=«IContract«
  7.   listenUriMode=«Explicit«
  8.   behaviorConfiguration=«CustomEndPointBehavior«/>

Tendremos solucionado el problema

The mapping and metadata information for EntityContainer ‘x’ no longer matches the information used to create the pre-generated views

 

Este error se produce cuanto trabajamos con pre-generated views en Entity Framework.

Este Post describe una forma de solucionar este error.

En el caso en particular que describo este es el escenario:

Base de Datos: Oracle, con distintos esquemas en función de cada entorno.

Proveedor de Datos: Devart

ORM: Entity Framework 4

Generación de pre-generated views: Mediante la plantilla T4

Entorno de compilación: Visual Studio Team Foundation Server 2010 Service Pack 1

Arquitectura: Proyecto basado en DDD utilizando la arquitectura n-layered de Codeplex.

El error se produce al desplegar una versión tras realizar una build en el TFS apuntando a un nuevo esquema de base de datos, cambio que realiza la propia build  con una custom activity sobre el fichero .edmx antes de compilar.

Pregenerated Views

Las pregenerated-views aportan una gran reducción de tiempo en proyectos que utilicen  Entity Framework.

La referencia a estas mejoras se pueden encontrar aquí:

http://msdn.microsoft.com/en-us/library/bb896240%28v=vs.90%29.aspx

El Problema

El error se produce por no ejecutar la plantilla T4 para regenerar las vistas después de haber modificado el fichero .edmx. Cuando se ejecuta la plantilla .tt mediante Run Custom Tool se genera un fichero .cs que incluye unas hash que Entity Framework utiliza para ver si ha variado la información de las vistas.

Esta hash se encuentra en el fichero .cs generado por la plantilla .tt

  1. namespace Edm_EntityMappingGeneratedViews
  2. {
  3.     
  4.     
  5.     /// <Summary>
  6.     /// The type contains views for EntitySets and AssociationSets that were generated at design time.
  7.     /// </Summary>
  8.     [System.Diagnostics.DebuggerNonUserCode()][System.CodeDom.Compiler.GeneratedCode(«EF»,«v 4.0»)]public sealed class ViewsForBaseEntitySetsD8764C9409F9061FB3ACFF9A2D927400C418BCF91616A573FD109E312323984A : System.Data.Mapping.EntityViewContainer
  9.     {
  10.         
  11.         /// <Summary>
  12.         /// The constructor stores the views for the extents and also the hash values generated based on the metadata and mapping closure and views.
  13.         /// </Summary>
  14.         public ViewsForBaseEntitySetsD8764C9409F9061FB3ACFF9A2D927400C418BCF91616A573FD109E312323984A()
  15.         {
  16.             this.EdmEntityContainerName = «EntitiesMant2»;
  17.             this.StoreEntityContainerName = «MantStoreContainer»;
  18.             this.HashOverMappingClosure = «b259ca6b447b5503d17e29d1089b9731f467487917f28b6e80b3ef67a296e833»;
  19.             this.HashOverAllExtentViews = «576048e78b6e27609be586140ddb9e3dc2abdc665cf47ddc76534fc80c15a8b9»;
  20.             this.ViewCount = 28;
  21.         }

 

El hash se genera en base al contenido del fichero .edmx con lo que cualquier cambio que hagamos en él dejara el hash invalidado y por lo tanto tendremos problemas.

Siguiendo la información reportada en el blog de Oleg Sych:

http://www.olegsych.com/2010/04/understanding-t4-msbuild-integration/#comment-3483

Y su referencia en MSDN

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

Encontré la solución que describo a continuación.

Resolución del Error

Para resolver el error es necesario:

Que todos los desarrolladores y en el servidor en el que hacemos la build, tengamos instalado:

Visual Studio 2010 SDK

Visual Studio 2010 Visualization & Modeling SDK

 

Una vez descargados modificaremos el fichero de proyecto (.csproj) que contiene el .edmx y la plantilla .tt, haciendo un unload y editándolo, agregando las siguientes entradas:

 

Fichero .csproj
  1. <Import Project=«$(MSBuildExtensionsPath)MicrosoftVisualStudioTextTemplatingv10.0Microsoft.TextTemplating.targets« />
  2.   <PropertyGroup>
  3.     <TransformOnBuild>false</TransformOnBuild>
  4.     <TransformOutOfDateOnly>false</TransformOutOfDateOnly>
  5.     <OverwriteReadOnlyOutputFiles>true</OverwriteReadOnlyOutputFiles>
  6.     <!– Other properties can be inserted here –>
  7.   </PropertyGroup>
  8.   <PropertyGroup>
  9.     <PreBuildEvent>«%25windir%25Microsoft.NETFrameworkv4.0.30319msbuild.exe» $(ProjectDir)Infrastructure.Data.proyecto.csproj /t:Transform /p:TransformFile=ModelDPTCampaignMant.proyecto.tt</PreBuildEvent>
  10.   </PropertyGroup>

Con estas entradas y el prebuildEvent conseguiremos que se ejecute la plantilla .tt volviendo a generar las vistas y cambiando los hash justo antes de que se ejecute la compilación.

WCF Guía Completa de Programación. CAP. II. Mi Primer servicio WCF

 

Introducción

Este en cualquier libro suele ser el típico ejemplo de “hola mundo”, sólo que en el caso de WCF creo que es bastante más divertido.

En el mejor de los casos para hacer una simple llamada vamos a tener que escribir un montón de código, esto que en un principio parece engorroso, a la larga cuando estemos construyendo aplicaciones complejas será una forma de poner orden a todo el mecanismo de desarrollo de aplicaciones distribuidas.

Componentes de una Aplicación WCF

Los que hayan trabajado con tecnologías antiguas basadas en COM o DCOM recordarán el duro camino de los CLSID para mantener las referencias entre clientes, servidores, servidores con servidores, etc.

la verdadera potencia de WCF es haber acumulado no sólo todas las tecnologías de aplicaciones distribuidas como Remoting, MSMQ, … Sino el haber utilizado el potencial de todo lo que se ha evolucionado en las arquitecturas internet B2B, SOAP…

Para estructurar una aplicación que exponga servicios y otra que los consuma, como veremos adelante es todo un mundo. De echo me atrevería a decir que el 70% de WCF es configuración o similar, mientras que el resto esta relacionado con el propio código.

En este capítulo no vamos a ver un ejemplo que sea el modelo a seguir para realizar una aplicación cliente o servidor WCF, pero si va a sentar las bases para entender todo lo que viene a continuación.

Por eso esta aplicación la escribiremos haciendo el menor número de líneas de código posibles y pasando por alto temas como poder extraer la configuración del código para llevarla a ficheros, ya que esto se verá más adelante.

WCF está totalmente relacionado con SOA, es más si no voy a a hacer una aplicación que necesite SOA debo plantearme si WCF es la solución. Estoy harto de ver proyectos donde la gente empieza a meter tecnologías a saco sin pensar si es lo correcto, sólo por estar a la última.

Debemos tener en cuenta que los principios de SOA son permitir el desarrollo de nuevos requerimientos de negocio sin tener que reconstruir toda la aplicación entera, así como poder tomar nuestros bloques de aplicación para construir bloques de procesos de negocio. Es decir que si alguien está pensando en utilizar WCF para cacharrear tecnológicamente lo debe pensar bien, puesto que el coste de horas de desarrollo es elevado y debe tener una contrapartida en el negocio que al final es quien contrata los sistemas.

Por otro lado el utilizar WCF en cierto modo nos abstraerá de tener que poseer determinados conocimientos como WSDL, etc. ya que WCF lo hará por nosotros.

Para definir WCF, hay que indicar que todo servicio está compuesto por al menos dos partes, el cliente y el servidor. El servidor expone los servicios y el cliente los consume, todo ello mediante el intercambio de mensajes.

Para que un cliente y un servidor se comuniquen es necesario establecer lo que se ha dado en llamar el ABC de WCF, que no es ni más ni menos que Address, Binding y Contract. O lo que es lo mismo.

  • Address: La dirección del servicio
  • Binding: El mecanismo de comunicación
  • Contract: Los servicios que se exponen.

Estas tres “cosas” juntas se denomina Endpoint que son los puntos de conexión entre cliente y servidor. Es decir un cliente envía y recibe la información a través de sus EndPoints, así como un servidor escucha y responde a través de sus EndPoints.

Unos ejemplos de estos tres elementos serían:

Address: http://servicios.acme.com:8001/serviciosuma

Binding:  BasicHTTPBinding

Contract: [OperationContract] int suma(int x,int y);

 

Construcción de un Sistema WCF Básico

Cómo he comentado anteriormente no se trata de hacer un servicio complejo con múltiples opciones de configuración, ficheros de configuración, distintos tipos de endpoints, etc. En este primer ejemplo se trata de probar unas mínimas piezas, ejecutar y decir “FUNCIONA!!” de tal forma que nos motive a seguir aprendiendo.

Otro tema a tener en cuenta es que los ejemplos que voy a poner en los distintos capítulos van a ser muy sencillos de entender, ya que lo importante no es averiguar que hace mi super ejemplo a nivel de negocio, sino entender la tecnología que se utiliza.

El Servidor

Pues para empezar lo primero que haremos será crear un Contrato, es decir construir algo que indique qué voy a exponer en mi servidor WCF.

Para ello crearemos un nuevo proyecto, lo haremos desde cero sin utilizar ninguna plantilla. Es el método que más me gusta, primero aprendemos por las bravas y luego wizards o similar, sino no hay quién entienda lo que se genera y como me enseño mi gran amigo Rido, cuando un wizard te genera algo que no entiendes, lo mejor es “quitarlo”. Qué Razón tienes Rido!!!

Un contrato de debe definir como una interface y en el proyecto debemos tener agregada la referencia a System.ServiceModel, que es el namespace que provee los objetos y atributos necesarios para construir servicios WCF.

image

Una vez agregada la referencia, podremos incluir la cláusula using Sytstem.ServiceModel en nuestro Proyecto.

En este primer proyecto, vamos a incluir una función muy sencilla en la que enviaremos  un par de enteros y la función nos devolverá la suma, resta, multiplicación o división, en función de lo que indiquemos. Es decir la típica calculadora.

Para ello definiremos primero el interface con los servicios que vamos a exponer.

[sourcecode language='csharp' ]
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
namespace IServicio
{
    [ServiceContract]
    public interface ICalculadora
    {
        [OperationContract]
        int sumar(int x, int y);

        [OperationContract]
        int restar(int x, int y);

        [OperationContract]
        int multiplicar(int x, int y);

        [OperationContract]
        decimal dividir(int x, int y);
    }
}
[/sourcecode]

En este código del interfaz, hemos de fijarnos en dos cosas.

El interfaz lleva el modificador [ServiceContract] que indica un nuevo grupo de operaciones o Contrato que estamos estableciendo.

También observamos como cada método lleva un modificador [OperationContract] que indica una Operación del Contrato que estamos estableciendo.

El Servicio

Una vez que hemos establecido nuestro Contrato hemos de implementar el servicio que desarrollará nuestro interfaz.

Lo haremos en un proyecto diferente que agregaremos a nuestra solución en el que implementaremos los cuatro OperationContract.

Este proyecto no presenta ninguna perculiaridad, salvo que agregamos como referencias el proyecto del interfaz y el espacio de nombres ServiceModel.

No se incluyen validaciones o similar por claridad del código, además de que el tratamiento de excepciones se verá más adelante.

El código completo del Servicio sería el siguiente:

[sourcecode language='csharp' ]
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
    
namespace Contratos
{
    public class Calculadora : ICalculadora
    {
      public  int sumar(int x, int y)
        {
            return x + y;
        }

      public  int restar(int x, int y)
        {
            return x - y;
        }


      public  int multiplicar(int x, int y)
        {
            return x * y;
        }


     public    decimal dividir(int x, int y)
        {
            return x / y;
        }
    }
}
[/sourcecode]

El Host

Para poder utilizar un servicio desarrollado mediante WCF será necesario alojarlo en un componente, existen varias posibilidades, tales como una aplicación de consola, un servidor IIS,…

Para nuestro primer ejemplo utilizaremos la aplicación consola y crearemos toda la configuración por código.

Para ello a nuestra solución agregaremos un nuevo proyecto de Consola.

Para poder  hostear el servicio WCF, hemos de indicar los siguientes elementos en nuestro código.

  1. ADDRESS. Definiremos la URL en la que expondremos el servicio y le asignaremos un nombre. En nuestro caso Calculadora
[sourcecode language='csharp' ]
Uri miurl = new Uri("http://localhost:8080/Calculadora");
[/sourcecode]
  1. BINDING. Especificaremos el protocolo de comunicación a nuestro servicio
[sourcecode language='csharp' ]
BasicHttpBinding elbinding = new BasicHttpBinding();
[/sourcecode]
  1. CONTRACT. Especificaremos el contrato de operaciones expuesto por nuestro servicio
[sourcecode language='csharp' ]
ServiceHost elhost = new ServiceHost(typeof(Calculadora), miurl);
[/sourcecode]

Después de estos tres pasos, del ya comentado ABC de WCF abriremos el Host mediante una instrucción Open e implementaremos un ReadLine sobre la consola para que no se nos cierre y se quede escuchando por la URL establecida.

 

[sourcecode language='csharp' ]
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
using Contratos;



namespace HostServicio
{
    class Program
    {
        static void Main(string[] args)
        {
            Uri miurl = new Uri("http://localhost:8080/Calculadora");
            ServiceHost elhost = new ServiceHost(typeof(Calculadora), miurl);

            BasicHttpBinding elbinding = new BasicHttpBinding();
            elhost.AddServiceEndpoint(typeof(ICalculadora), elbinding, "");

            elhost.Open();

            try
            {
                Console.WriteLine("Servicio alojado en " + miurl.AbsoluteUri);
                Console.ReadLine();
            }
            finally
            {
                elhost.Close();
            }
        }
    }
}
[/sourcecode]

Tras haber creado el Host, el siguiente paso es arrancarlo, para ello haremos un Build de la solución y arrancaremos la aplicación de consola desde la carpeta BinDebug ejecutando como Administrador si estamos trabajando con Windows 7, Vista,….

image

También podemos abrir la consola “como administradores” y navegar hasta la carpeta para ejecutar el host a mano

image

En cualquiera de los casos nuestra aplicación quedará levantada indicandonos el mensaje que hemos introducido.

image

         Para verificar que nuestro servicio está expuesto desde el internet explorer introduciremos la URL que indicamos en el apartado Address del código de la aplicación HOST.

image

En esta imagen podemos observar quela aplicación servidor ha desplegado nuestro servicio pero que el Metadata esta deshabilitado actualmente, es decir, que las operaciones no están expuestas vía WSDL, esto se puede desactivar por configuración, pero en nuestro caso de momento lo vamos a hacer por código mediante la inclusión de las siguientes líneas:

[sourcecode language='csharp' ]
 ServiceMetadataBehavior metadatos = new ServiceMetadataBehavior();
            metadatos.HttpGetEnabled = true;
            elhost.Description.Behaviors.Add(metadatos); 
[/sourcecode]

Con las que indicamos que queremos mostrar el Metadata, es decir mostramos la información del interface Contrato mediante reflexión de los servicios que hayamos expuesto mediante el modificador [OperationContract]

Una vez incluidas estas líneas, si recompilamos y volvemos a introducir la url del servicio en el navegador, nos aparecerá una ventana que nos indica que mediante la herramienta svcutil podemos generar varios ficheros tales como el PROXY, necesario para nuestro cliente.

image

El código completo por lo tanto del Host sería el siguiente:

[sourcecode language='csharp' ]
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
using Contratos;
using System.ServiceModel.Description;



namespace HostServicio
{
    class Program
    {
        static void Main(string[] args)
        {
            Uri miurl = new Uri("http://localhost:8080/Calculadora");
            ServiceHost elhost = new ServiceHost(typeof(Calculadora), miurl);

            BasicHttpBinding elbinding = new BasicHttpBinding();
            elhost.AddServiceEndpoint(typeof(ICalculadora), elbinding, "");

            ServiceMetadataBehavior metadatos = new ServiceMetadataBehavior();
            metadatos.HttpGetEnabled = true;
            elhost.Description.Behaviors.Add(metadatos); 

            elhost.Open();

            try
            {
                Console.WriteLine("Servicio alojado en " + miurl.AbsoluteUri);
                Console.ReadLine();
            }
            finally
            {
                elhost.Close();
            }
        }
    }
}
[/sourcecode]

El Cliente

El cliente que vamos a utilizar será una aplicación Winforms, muy sencilla en la incluiremos dos cajas de texto para los número x e y que está esperando nuestro servicio, además de unos botones para realizar las operaciones.

Para poder utilizar el cliente necesitamos el proxy, el cual generaremos mediante la utilidad svcutil como hemos indicado anteriormente. De momento añadiremos la clase proxy y más adelante en otros capítulos explicaremos en detalle el por qué del proxy.

Para ello arrancamos el símbolo del sistema que viene con el propio Visual Studio y ejecutamos el comando atacando a la URL en la que tenemos arrancado nuestro servicio mediante la consola.

image

Por su puesto la llamada la haremos desde la carpeta del cliente, así se nos generará en esta carpeta el proxy .cs que agregaremos al proyecto posteriormente.

image

image

Podemos ver que se ha generado el .cs con el proxy el cual incorporamos a nuestro proyecto cliente.

image

El proyecto Cliente es muy sencillo, se codificará sólo el método sumar y se dejará el resto en el código fuente para que quién se lo descargue pueda finalizar el ejemplo.

Para poder utilizar el servidor es necesario agregar las referencias a ServiceModel y utilizar la clase que nos ha generado la herramienta svcutil.

En el código del cliente cabe destacar:

La creación del Endpoint de Cliente

[sourcecode language='csharp' ]
 EndpointAddress ladireccion = 
                new EndpointAddress("http://localhost:8080/Calculadora");
            BasicHttpBinding elbinding = new BasicHttpBinding();
[/sourcecode]

La utilización del proxy

[sourcecode language='csharp' ]
 CalculadoraClient lacalculadora = 
                new CalculadoraClient(elbinding, ladireccion);
[/sourcecode]

La llamada al método sumar

[sourcecode language='csharp' ]
  MessageBox.Show("Resultado " +
                lacalculadora.sumar(int.Parse(txtX.Text), 
                int.Parse(txtY.Text)).ToString());
[/sourcecode]

El código completo del cliente sería:

[sourcecode language='csharp' ]
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.ServiceModel;

namespace Cliente
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void cmd_add_Click(object sender, EventArgs e)
        {
            EndpointAddress ladireccion = 
                new EndpointAddress("http://localhost:8080/Calculadora");
            BasicHttpBinding elbinding = new BasicHttpBinding();

            CalculadoraClient lacalculadora = 
                new CalculadoraClient(elbinding, ladireccion);

            MessageBox.Show("Resultado " +
                lacalculadora.sumar(int.Parse(txtX.Text), 
                int.Parse(txtY.Text)).ToString());

            
        }
    }
}
[/sourcecode]

Como podemos ver si ejecutamos nuestro servidor y nuestra consola, la llamada FUNCIONA!!!

 

image

Este es el primer paso, a partir de ahora en los siguientes capítulos se irá avanzando en configuración, contratos, seguridad, etc.

 

Código Completo.

El código completo de este primer capítulo lo podéis descargar desde aquí:

Capitulo1.zip

WCF Guía Completa de Programación. CAP. I. Introducción

 

Prólogo

Después de un tiempo trabajando con WCF me estaba empezando a plantear escribir un libro, un libro útil desde el punto de vista práctico que da el trabajar en proyectos.

Como tras evaluarlo detenidamente, supuse que esto me iba a suponer bastante tiempo del que no dispongo (ya sabemos todos lo que es este trabajo de la informática…) pues he decidido en reducirlo al máximo y publicarlo en mis blogs para que además esté al alcance de todos. Hasta a mi alcance, que a veces uno no se acuerda de cosas y tiene que echar mano “del internet”.

El principal problema cuando coges un libro es que depende mucho de quién lo haya escrito, para que podamos decir que este libro que habla de tal tecnología es un buen libro, no sólo tiene que tratar los temas a fondo, sino que tienen que ser prácticos.  Esto a lamentablemente no pasa a menudo en los libros técnicos, aunque últimamente  y en concreto los libros de Microsoft han mejorado bastante.

En resumen lo que voy a intentar en sucesivos capítulos es tratar una de las tecnologías que más me han atraído en los últimos tiempos, quizá por la añoranza de aquellos años en que los que comenzamos a trabajar con DCOM nos sentíamos como aventureros, en un mundo como poca información en el que el prueba error era una constante.

Introducción.

Una vez situados en antecedentes, creo que lo mejor es ver lo que sucesivamente voy a ir publicando, espero que con cierta constancia, en sucesivos Post, los cuales harán el libro, mini-libro, o guía como le queráis llamar de desarrollo con WCF.

Intentaré poner ejemplos completos para lo que utilizaremos una base de datos que publicaré como enlace descargable, cuando lleguemos al punto en el que accedamos a datos.

Si estuviera escribiendo un libro de verdad, pues habría capítulos dedicados a una introducción real de que es WCF y demás paja, que creo que lo mejor es que nos los saltemos y pasemos directamente a la “chicha”. Mi intención es publicar 1 o 2 capítulos a la semana, los cuales estaré encantado de completar con vuestros comentarios y sugerencias.

Con esto dicho, los distintos temas que trataré serán:

  1. Mi Primer servicio WCF
  2. Contratos
  3. Nociones Básicas de Configuración WCF.
  4. Hosting de Servicios WCF
  5. Configuración Avanzada
  6. Instrumentación en WCF
  7. Seguridad
  8. Transacciones
  9. El mundo Real

En los próximos días subiré el primer post. Espero que os guste la idea y el que quiera aportar con algún otro tema que no vaya a contemplar que me lo comente.

Herramienta de Desinstalación de Visual Studio 2008

  Bueno, me imagino que en alguna ocasión habréis tenido que desinstalar Visual Studio 2008, lo cual supone una tarea nada fácil, por no decir que algunas veces se hace imposible.

   En unas de estas ocasiones un compañero me recomendó la herramienta que pongo aquí para los que la necesitéis.

  Eso sí en hacer la limpieza tarda un buen rato…

  Pulsa en el enlace para descargártela   UninstallTool.zip

Foro de Arquitectos Microsoft

El otro día tuve el gusto de asistir al foro de arquitectos de Microsoft, en el que mi viejo amigo Cesar de la Torre (http://blogs.msdn.com/cesardelatorre/), junto con Unai Zorrilla presentaron una iniciativa de la construcción de una arquitectura base (n-capas) para el desarrollo de proyectos grandes sin acoplamiento.

Ya era hora que desde Microsoft alguien nos diera un punto de partida para no reinventar la rueda en cada proyecto.

Enhorabuena por ellos!!

La información general la podéis encontrar aquí: http://msdn.microsoft.com/es-es/architecture/default.aspx

Y la solución para descargar, en codeplex:

http://microsoftnlayerapp.codeplex.com/

Esperemos que ambos continuen con la iniciativa e incorporen las nuevas tecnologías que puedan aparecer.