Uno de los clientes de 3Metas tiene una base instalada muy importante de aplicaciones construidas en Visual Fox Pro 7, 8 y 9. Durante los últimos meses hemos trabajado en conjunto para desarrollar una estrategia de migración de estas aplicaciones hacia una arquitectura orientada a servicios (SOA) construida con WCF y el Framework 3.5 de .Net.

Uno de los aspectos claves de un proceso como estos consiste en evitar al máximo que se siga construyendo funcionalidad en Visual Fox Pro (VFP) así que el primer paso de la estrategia consiste en la integración de VFP con servicios de Windows Communication Foundation (WCF) de forma tal que las aplicaciones actuales se vean beneficiadas de las mejores en la lógica de negocios o de nuevas funcionalidades que se construyen con la última tecnología disponible.

1. Lo primero que debe hacerse es construir un servicio de WCF en lo que no profundizare especialmente.

2. En nuestro caso una vez que tuvimos construido el servicio construimos una fachada para su utilización desde VFP.

3. En esta fachada establecemos las referencias a los servicios por medio de la herramienta de Visual Studio, allí verificamos el tipo de conversión que se realizará sobre las colecciones genéricas. Como queremos proteger la inversión del cliente en este proyecto esta fachada deberá poderse usar desde VFP pero también desde aplicaciones desarrolladas con .Net hoy y en el futuro.

4. Creamos una clase que estará visibles por COM desde VFP y que será la fachada para esta herramienta.

5. Esta clase debe estar decorada como COM visible [ComVisible(true)] y para asegurar las opciones de Intellisense también agregamos la decoración de generación de la Interfaz [ClassInterface(ClassInterfaceType.AutoDual)]

6. Aunque visual Studio 2008 (VS2008) crea el constructor de forma predeterminada preferimos asegurarnos así que agregamos el constructor, tener presente aquí que el constructor no puede sobrecargarse ni recibir parámetros para evitar problemas en COM

7. Luego creamos los métodos que serán consumidos por VFP y se los decora como visibles para COM [ComVisible(true)].

8. En nuestro caso los métodos del servicio de WCF devuelven colecciones genéricas de tipos específicos, por ejemplo la colección de colores de la entidad color: [CollectionDataContract(Name = "Colores", Namespace ="http://myDomain.com/Data/2010/01")] public class Colores: Collection<ColorEntity> {}, para que estos métodos puedan ser consumidos desde VFP y teniendo en cuenta la restricción de COM para el manejo de genéricos se realiza una modificación al método para que no retorne la colección sino que retorno un arreglo de objetos que es algo que si puede ser manejado por VFP, la posibilidad de convertir la colección genérica en un arreglo se adiciono con LINQ, así que debe establecerse la referencia a LINQ en el proyecto y la clase, al final debe quedar algo como esto:

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Linq;

   4:  using System.Text;

   5:  using System.Runtime.InteropServices;

   6:  using ServicioProducto;

   7:  

   8:  namespace ServicesFacade

   9:  {

  10:  

  11:      [ComVisible(true)]

  12:      [ClassInterface(ClassInterfaceType.AutoDual)]

  13:      public class ProductoFacadeVFP

  14:      {

  15:          //default constructor

  16:          public ProductoFacadeVFP() {}

  17:  

  18:          /// <summary>    

  19:          /// Metodo trae los colores del Sistema

  20:          /// </summary>

  21:          /// <returns></returns>

  22:          [ComVisible(true)]

  23:          public Color[] GetColores()

  24:          {

  25:              Colores colores = null;

  26:  

  27:              try

  28:              {

  29:                  ServicioProductoClient srv = new ServicioProductoClient();

  30:                  colores = srv.GetColores();

  31:                  srv.Close();

  32:              }

  33:              catch (Exception ex)

  34:              {

  35:                  throw ex;

  36:              }

  37:  

  38:              return colores.ToArray();

  39:          }

  40:       }

  41:  }

9. Al compilar este proyecto se obtendrá una DLL y un archivo de configuración que corresponde a la forma como se establecerá la comunicación con el servicio (Address y Bindings), estos dos archivos son los que deben entregarse a los desarrolladores de VFP para que consuman los servicios.

Completada la fase de preparación y construcción de los servicios y su fachada los desarrolladores de VFP ya pueden integrar estos componentes en sus aplicaciones, para ello deben realizarse las siguientes actividades:

1. Registrar la Interfaz COM de la fachada de los servicios por medio del comando regasm, idealmente debería utilizarse el parámetro CODEBASE, la instrucción sería algo como esto si se corre desde el directorio del Framework 2.0 de .Net: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>RegAsm.exe “C:\3Metas\Clients\Cliente\Proyecto\ServiceFacade\ ServicesFacade.dll” /CODEBASE

2. Uno de los aspectos más importantes de WCF es la separación de la configuración del servicio del código, el address y el binding del servicio que están definidos en el archivo de configuración, este archivo de configuración se generó al compilar la fachada. Para cada proyecto en el que va a utilizarse la fachada se debe copiar el archivo de configuración del servicio en la misma ruta del ejecutable de la aplicación de VFP o para depuración en la ruta donde reside el proyecto, este archivo debe renombrarse con el nombre de la aplicación de VFP y la extensión .config, en nuestro caso queda algo como esto: aplicaciondelcliente.exe.config. Muchos de los errores que se pueden presentar al usar la fachada tienen que ver con el hecho de que la aplicación no encuentra el archivo de configuración.

3. Registrada la interfaz COM de la fachada y renombrado y ubicado correctamente el archivo de configuración del servicio ya está todo listo para que el desarrollador pueda utilizar los servicios desde VFP. Solo debe utilizar el método CREATEOBJECT con el nombre de la clase de la fachada. Por ejemplo:

   1:  LOCAL Colores

   2:  LOCAL MyColor as ServiceFacade.ServicioProducto.Color

   3:  LOCAL ProductoFacade as ServicesFacade.ProductoFacadeVFP

   4:  

   5:  ProductoFacade = CREATEOBJECT("ServicesFacade.ProductoFacadeVFP")

   6:  Colores = ProductoFacade.GetColores()

   7:  

   8:  OPEN DATABASE "C:\3Metas\Clients\Integration\sampledata" EXCLUSIVE

   9:  USE color IN 0 EXCLUSIVE ALIAS tblColor

  10:  ZAP

  11:  

  12:  FOR EACH Item IN Colores

  13:      INSERT INTO color (ColorId) VALUES (Item.ColorId)

  14:  ENDFOR

Listo, el equipo de desarrolladores de VFP está consumiendo servicios de WCF.

Aclaraciones importantes:

· Con Visual Fox Pro se pueden consumir servicios Web, así que si se exponen los servicios de WCF con un binding básico HTTP el servicio de WCF se ve exactamente igual que un servicio web y por tanto se consume sin problemas desde FoxPro, sin embargo desde la perspectiva técnica puede llegar a tener problemas con objetos de negocios que VFP no entienda o que el servicio de WCF este expuesto por otro binding lo que haría imposible consumirlo desde VFP nativo, en nuestro caso las aplicaciones no estaba construidas consumiendo servicios web y el cliente no quería invertir tiempo de los desarrolladores en que aprendieran a consumir servicios web desde VFP, de allí tenía sentido que ellos consumieran objetos COM que les son familiares.

Al crearse el proyecto de fachada podría configurarse por medio de VS2008 la conversión de las colecciones genéricas en arreglos (ARRAYS). Sin embargo, eso haría que la fachada perdiera tipos de datos que podrían ser utilizados por clientes de .Net

En 3Metas utilizamos las últimas tecnologías en desarrollo de software, por eso muchas de nuestras aplicaciones trabajan bajo la arquitectura de servicios (SOA).  Por esta razón en uno de nuestros clientes usamos servicios de Windows Communication Foundation para compartir datos entre diferentes plataformas y aplicaciones como por ejemplo Windows Mobile, Aplicaciones WPF, Aplicaciones Silverlight y ASP.NET.

Una de las tareas que debemos realizar después de crear estos servicios es la publicación de los mismos en un servidor web para que sean expuestos y utilizados por las diferentes aplicaciones. En este pequeño tutorial publico los servicios en un servidor web IIS 7 con Windows Server 2008.

1. Se crea un sitio web, se le asigna un puerto específico, en el caso de nuestro cliente,  es el puerto 81 el que utilizan los servicios  WCF. Sin embargo podemos escoger cualquier puerto y verificar que este puerto este abierto en el firewall si los servicios van a  estar expuestos a internet.

2. Se copian los archivos publicados de la solución de los servicios en una carpeta específica, que es la misma que se ha definido al momento de crear el sitio web en el IIS.

3. Nos aseguramos que el namespace  ServiceModel este activo y registrado en nuestro servidor IIS, para ello abrimos la consola de comandos en modo administrador y ejecutamos el siguiente comando: “%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe” -r –y

4. La ejecución de este comando nos muestra unos resultados como parece en la siguiente figura

5. Se revisan los Handler Mappings como se ve en la figura:

6. Doble clic sobre Handler Mapping, aparece la siguiente pantalla:

7. En esta pantalla revisar si existen las entradas para la definición de los *.svc, ya que en nuestro caso los Hosting de los servicios WCF son en IIS con ASP.NET.

8. Para crear estos handlers hacemos clic derecho sobre la lista, nos muestra el siguiente menú:

9. Seleccionamos la primera opción  Add Managed Handler que nos muestra la siguiente pantalla en la cual colocamos los datos a ingresar:

8. Los valores a colocar para Request path: *.svc, Type: System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Name: svc-Integrated. Las restricciones las dejamos por default. Este es el primer registro. Debemos colocar otros 2 registros.

9. Los valores a colocar para Request path: *.svc, Type: %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll, Name: svc-ISAPI-2.0. Las restricciones las dejamos por default. Este es el segundo registro.

10. Los valores a colocar para Request path: *.svc, Type: %SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll, Name: svc-ISAPI-2.0-64. Las restricciones las dejamos por default. Este es el tercer registro si es para un servidor de 64 bits.

11. Luego verificamos si nuestros servicios quedaron funcionando de manera correcta, en la pantalla siguiente:

12. Seleccionamos un servicio, como el que se muestra en la figura, clic derecho y en el menú que aparece le damos Browse, lo cual nos abre una ventana del explorador de internet para verificar si nuestro servicio está funcionando de manera correcta.

13. El explorador de internet nos debe mostrar una pantalla como la siguiente: indicando que el servicio está funcionando correctamente.

14. El siguiente paso es corregir en el web.config del sitio ASP.NET que hostea u hospeda  los servicios WCF, las cadenas de conexión a las bases de datos que utilizamos para que nuestros servicios puedan funcionar de manera correcta.

En nuestro caso verificamos la sección ConnectionStrings del web.config y colocamos los valores correctos:       <connectionStrings>

<add name=”XXXXXNETDB” connectionString=”Data Source=YYYYY;Initial Catalog=MiBaseDatos;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

<add name=”XXXXXNETDBII” connectionString=”Data Source=YYYYY;Initial Catalog=MiOtraDB;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

<add name=”ZZZZDB” connectionString=”Data Source=YYYYY;Initial Catalog=JJJJJJ;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

</connectionStrings>

15. El siguiente paso es ir a la solución que consume los servicios que estamos exponiendo en el IIS en nuestra solución ASP.NET a través de los archivos *.svc  y colocar la dirección correcta de cada uno de los servicios en el app.config si es una aplicación  Windows, o en el web.config si es una aplicación web.

Verificamos y cambiamos el endpoint de los Servicios WCF que estemos exponiendo en nuestra aplicación :

<endpoint address=”http://servidor:81/ServicioRendimientos.svc”

binding=”wsHttpBinding” bindingConfiguration=”WSHttpBinding_IServicioRendimientos”

contract=”ServicioRendimientosClient.IServicioRendimientos”

name=”WSHttpBinding_IServicioRendimientos”>

<identity>

<dns value=”localhost” />

</identity>

</endpoint>

16. Como podemos observar en el tag address=http://servidor:81/ServicioRendimientos.svc, hemos cambiado a servidor:81 que es el nombre del servidor y el puerto por donde definimos en el sitio que se va a exponer los servicios WCF.

17. Probar nuestra aplicación que consume los servicios para comprobar que todo esté funcionando como debe ser.

Bueno eso es todo por ahora, espero haber podido ayudarles en este proceso de instalación de los servicios WCF en un servidor IIS.

En 3Metas usamos Visual Studio Team Fundation Server como sistema de gestión de proyecto y control de versiones, sin embargo al momento de crear las soluciones cometí un error por no revisar con cuidado la guía de Branching de Patterns And Practices de Microsoft lo que me llevó a quedar con los proyectos y la documentación andando pero con un esquema incorrecto de control de código fuente. La solución es borrar (destruir) los repositorios de Código Fuente (previo backup por supuesto ) y reorganizar el sistema.

Para destruir un repositorio de código Fuente, se utiliza el comando tf destroy, (Btw: se encuentra en la ruta Program Files\Microsoft Visual Studio 9.0\Common7\IDE>) desde la consola de comandos, una confirmación de borrado aparecerá y luego se listaran los archivos y carpetas que se eliminaron.

Después de borrado puede usarse VS2008 con el Team Explorer para volver a la interfaz de gestión de los sistemas de control de código fuente y allí crear de nuevo el repositorio y configurarlo correctamente. Es importante anotar que hay que volver a asignar los permisos a los usuarios que aunque siguen teniendo permisos en el TFS en el Proyecto al que están asignados ahora no tienen permisos en el repositorio de control de versiones. Estos permisos se asignan en la pestana de seguridad de las propiedades del repositorio

(El borrado no es lo mismo, el borrado solo marca el repositorio pero sigue existiendo en el sistema se puede ver aquí: Tools > Options > Source Control > Visual Studio Team Foundation Server and check Show deleted items in the Source Control Explorer que los archivos no se borraron)

(Esto también es diferente a la eliminación del proyecto porque yo no quería perder el portal, documentos, work ítems, etc que ya se habían alimentado al sistema)

Los gadgets son aplicaciones web que se ejecutan a través del sidebar de Windows Vista y Windows 7. Su funcionalidad puede ser tan potente como la creatividad y experiencia de los desarrolladores se lo permitan. Gracias a la inclusión de JScript, Ajax y JQuery el alcance de estas aplicaciones se incrementa gradualmente.

Personalmente creo que dos de los principales inconvenientes para desarrollar este tipo de aplicaciones es lograr tener una idea que encaje en unos cuantos pixeles y realizar la depuración. Este último punto es la idea de este post.

Lo primero que debemos hacer es realizar el deployment del gadget que deseamos depurar, para esta tarea usamos Visual Studio 2008 realizando la publicación del gadget en el folder del sistema operativo donde por defecto se hospedan los gadgets:

· %USERPROFILE%\AppData\Local\Microsoft\Windows Sidebar\Gadgets (gadgets del usuario)

· %SYSTEM_ROOT%\Program Files\Windows Sidebar\Gadgets (gadgets globales)

Así que sobre el proyecto del gadget, damos click derecho y seleccionamos la opción Publish

Esto nos mostrará la ventana de publicación, en la cual colocamos en el path de publicación la ruta de instalación del gadget y seleccionamos la opción Delete all existing files prior to publish.

Una vez terminada la publicación procedemos a realizar la instalación del gadget en el sidebar dando click derecho sobre la zona de sidebar del escritorio y seleccionando la opción Agregar gadgets y agregando el que acabamos de publicar.

Con el gadget ya en el sidebar procedemos a configurar las opciones del browser para que se habilite la depuración de Scripts. Ejecutando entonces Internet Explorer, seleccionamos la opción Herramientas, seguida de Opciones de Internet y luego la pestaña Opciones Avanzadas, donde desmarcamos el check Deshabilitar la depuración de scripts (otros).

Procedemos ahora a configurar Visual Studio 2008 para iniciar el proceso de depuración. Para lo cual colocamos los break point necesarios donde deseamos que se detenga la ejecución de la aplicación y luego seleccionamos en el menú principal la opción Debug, seguida de Attach to Process.

Esto nos mostrará la ventana de procesos disponibles que actualmente se están ejecutando en el sistema operativo de nuestra máquina. En esta ventana buscamos el proceso que hace referencia al gadget que deseamos depurar y se está ejecutando en la Sidebar de Windows. Seleccionamos el proceso que hace referencia al gadget y luego damos click en el botón Attach.

Finalmente realizamos las acciones necesarias sobre el gadget que está en la sidebar para que se detenga la aplicación en los break points que hayamos establecido.

Antes de seguir los siguientes pasos, es necesario descargar Microsoft Report Viewer Redistributable.

Al realizar la publicación en IIS7 de un reporte en formato .rdlc embebido en una pagina aspx, nos encontramos que después de agregar nuestra aplicación web en IIS y dentro de su contenido copiar los archivos publicados en Visual Studio, vamos acceder a nuestra reporte (http://LocalHost/aplicacionReporte/reporte.aspx) y al realizar alguna consulta, el control ReportViewer esta deshabilitado.

La razón de esto es: cuando el control ReportViewer se añade al formulario web (Aspx), el httpHandler  Reserved.ReportViewerWebControl.axd se añade a  la sección System.Web del archivo web.config. En IIS7, este debe añadirse bajo la sección System.Webserver del archivo web.config. En IIS7 las Asignaciones de Controlador  no tiene un httpHandler del tipo Microsoft.Reporting.WebForms.HttpHandler (Reserved.ReportViewerWebControl.axd) y, por lo tanto es incapaz de habilitar los elementos del ReportViewer que necesita JavaScript.

Solución:

1. Abra Servicios de Internet Information Server (IIS) y seleccione la aplicación Web.
2. Bajo el menú IIS, haga doble clic en Asignaciones de Controlador.
3. En el panel derecho haga clic en agregar controlador administrado.
4. En el cuadro de dialogo de  agregar controlador administrado, escriba lo siguiente:

Ruta de Acceso de Solicitudes: Reserved.ReportViewerWebControl.axd

Tipo: Microsoft.Reporting.WebForms.HttpHandler

Nombre: Reserved-ReportViewerWebControl-axd

1. Haga clic en aceptar.

El manejador ó Handler, Reserved-ReportViewerWebControl-axd esta añadido ahora a su lista de asignaciones de controlador. Observe que la siguiente línea también ha sido añadida a su archivo web.config bajo la sección del manejador ó handler System.WebServer:

<add path=”Reserved.ReportViewerWebControl.axd”
verb=”*” resourceType=”Unspecified”
/>

WinMerge es una excelente herramienta para comparar archivos que puede facilitar en gran medida esta tarea en Visual Studio Team System. Aunque VSTS ya cuenta con una herramienta de comparación desde mi punto de vista no es muy práctica ni intuitiva.

Lo primero que tenemos que hacer es realizar la descarga de WinMerge la cual la pueden hacer acá. Una vez hecha la descarga, procedemos a la instalación de la herramienta.

Configuración de WinMerge en VSTS

1. Abrir Visual Studio Team System y en la barra de Menús, seleccione la opción Tools y luego Options.

2. En la ventana Options, seleccione la opción Source Control y luego Visual Studio Team Foundation Server.

3. Ahora damos Click en el botón del lado derecho Configure User Tools.

4. Este botón nos muestra la ventana para poder configurar WinMerge como herramienta de Merge y Compare.

5. Seleccionamos el botón Add y esto nos mostrará la ventana donde ingresamos la información de configuración necesaria.

6. Ingresamos la siguiente información para configurar la herramienta de Compare:

· Extension, escribir *

· Operation, seleccione Compare

· Command, seleccione el path donde quedó instalado WinMerge C:\Program Files\WinMerge\WinMerge.exe

· Arguments, escribir /e /x /s /wl /dl %6 /dr %7 %1 %2

· Click en OK para aceptar

7. Ingresamos la siguiente información para configurar la herramienta de Merge:

· Extension, escribir *

· Operation, seleccione Merge

· Command, seleccione el path donde quedó instalado WinMerge C:\Program Files\WinMerge\WinMerge.exe

· Arguments, escribir /e /s /x /ub /dl %6 /dr %7 %1 %2 %4

· Click en OK para aceptar

8. Ahora tenemos ya configurada las WinMerge como herramienta de Merge y Compare en VSTS

Con esta configuración ahora cuando necesitemos hacer tareas de Merge o Compare se harán a través de WinMerge.