MSDN Blogs
  • WarNov Developer Evangelist

    Mono Tools for Visual Studio

    • 4 Comments

    Cada vez que encuentro noticias como esta me siento bastante agradado pues nunca me ha gustado cuando dicen por ahí que la tecnología Microsoft es cerrada y para nada extensible a otras plataformas. Y el agrado surge básicamente de que obtengo cada vez más argumentos para demostrar lo contrario.

     

     

    En esta ocasión, la gente de Novell llega con este brillante producto. Aquél que nos permitirá a nosotros desarrolladores de software cuyo cubil de trabajo no es otro más que Visual Studio, tener nuestras creaciones en Linux, Unix y hasta MacOS, sin necesidad de aprender lenguajes ni plataformas nuevas.

    image

    Es un Add-In comercial (versión gratuita de evaluación) que se instala en Visual Studio y que permite entre otras cosas hacer escaneos de nuestras aplicaciones para ver si podrán correr bien sobre el Framework Mono (versión del Framework.Net para plataformas no Windows), hacer pruebas de nuestras aplicaciones usando Mono en Windows o en una imagen virtual de Linux, hacer debug remoto en Linux, empaquetar para Linux estándar o mediante un Appliance para SUSE Linux que proveerá un servicio de deployment muy sencillo para nuestra aplicación.

     

     

    Imaginen entonces qué cantidad de trabajo nos podremos ahorrar a la hora de programar nuevas aplicaciones .NET que queramos que corran en las plataformas no Windows, pero sobretodo la posibilidad de poder reusar todos los componentes que ya existen!

     

     

    Todo esto nos permitirá a nosotros, a los ISVs y proveedores de servicios de desarrollo expandir nuestras oportunidades de mercado de una manera muy sencilla. Sobretodo viendo que en el mercado actual, hay muchas instalaciones no Windows.

    image

    Además, para aquellos acostumbrados a desarrollar en otras plataformas, puede ser una oportunidad para explorar nuevas formas de desarrollo (Con Visual Studio) que de seguro harán que vean todas sus ventajas sobre los modelos de desarrollo que han usado siempre para llegarle a plataformas como Linux o MacOS. El sitio oficial de Mono Tools for Visual Studio se encuentra en este link.

     

     



  • WarNov Developer Evangelist

    Sistemas POS que piensan en la Nube

    • 2 Comments

    Antes que nada, veamos algunos requerimientos urgentes de los sistemas POS, dadas las condiciones económicas de hoy en día:

    ·         Puntos con funcionalidad extendida, pero con máxima velocidad y disponibilidad

    ·         Conexión directa con un ERP central para permitir decisiones óptimas y oportunas

    ·         Apertura para la colaboración con partners y otros servicios para reducir costos

    ·         Desarrollo y despliegue de software rápido y económico

    ·         Nada de inversiones iniciales en infraestructura

    En primera medida uno pensaría en SaaS como una alternativa. Pero usualmente los thin clients (browsers) no son capaces de trabajar offline. De esta manera se hace obvia la necesidad de un Front Store o repositorio en cada cliente. Además los browsers no pueden garantizar el manejo de periféricos ni pueden garantizar las velocidades requeridas en las cajas.

    Por todo esto, la mejor elección es usar Smart Clients con un caché de datos local usando por ejemplo SQL CE en cada cliente. El deployment se puede implementar usando ClickOnce. Sumado a esto pueden estar los protocolos WS-* que permiten una seguridad máxima sin tener que recurrirse a VPN u otras complicadas configuraciones de Firewall, así que las instalaciones serían muy sencillas.

    BEDIN Shop Systems, un ISV italiano creó la solución aKite enfocada a crear POS usando esta metodología. En un principio toda esta solución era auto hosteada y aunque solucionaba los problemas descritos, presentaba problemas a la hora de manejar picos de consumo y sobretodo de generar un esquema centralizado de integración con otros sistemas como el ERP, CRM, BI, Logística y demás...

    Con la llegada de Azure a producción, este ISV decidió migrar su aplicación y lo logro en solo tres meses sin mayores problemas, según su reporte.

    Esquema de POS comunicado con Azure

    Lograron crear un Hub Inteligente que remueve la complejidad técnica y facilita compartir datos entre los POS y otros sistemas. Por ejemplo en el caso de tarjetas de fidelidad y de regalo, se logró una inmediatez total, un mejor servicio y sobretodo menor riesgo de fraude.

    Además gracias al esquema nativo de Azure, los picos de uso dejaron de ser problema y sobretodo, cuando un cliente va a implementar su sistema POS, el up-front (o inversión inicial) es nulo, pues toda la infraestructura ya existe.

    Las ventas en este sistema pueden efectuarse desde todos los continentes, con distintos lenguajes, monedas e impuestos. Luego de esto, a través de los “Retail Web ServicesaKite RWS-” (creados por el ISV y hospedados en Azure usando SQL Azure) los datos se envían a un ERP central para actualizar el inventario y la contabilidad. Las estadísticas de ventas también se hacen inmediatamente disponibles, pero no solo en el ERP, sino también en los sistemas de Back Store.

    aKite RWS es un conjunto de servicios WCF que explotan muchas características de esta tecnología. De esta manera, solo fue necesario crear un conjunto claro de servicios, cuya configuración se adapta a cualquiera de los puntos de conexión requeridos. Por ejemplo, solo bastó con configurarlos para el uso con Smart Clients, y quedaron listos para usarse en los clientes POS.

    Como si fuera poco, la migración de estos servicios a Azure, generó valores agregados como un balanceo de carga automático (nativo de Azure), asegurando gran escalabilidad y una subdivisión más equitativa de los recursos entre las tareas. Antes eso era manejado por una aplicación bastante compleja y difícil de mantener.

    El proyecto fue dividido en un Web Role y cuatro Worker Roles que se comunican entre ellos usando Queues y Blobs. BEDIN declara que en la migración de datos y código de ORM no tuvo ningún problema, dado que Sql Azure demostró ser completamente compatible con el código de Sql Server que ya se tenía, aun cuando este había sido generado con un ORM de un tercero (LLBL GenPro)

    Como ISV, BEDIN también confirmó los siguientes beneficios:

    ·         Ausencia de costos iniciales en Hardware

    ·         Costos proporcionales en relación al número de usuarios

    ·         Ahorros que se pueden destinar a mercadeo, ampliación de funcionalidad y costos que se transfieren al usuario final en forma clara

    ·         Monitoreo automático

    ·         Auto recuperación de desastres

    En conclusión, Windows Azure permitió a BEDIN Shop Systems concentrarse en su aplicación y habilidades arquitecturales y en ofrecer un valor máximo a sus usuarios. Es una empresa con más de 20 años de experiencia en el desarrollo de POS. Fueron los pioneros en implementar .NET con aplicaciones para el Retail. (: www.bedin.it  www.akite.net )

     

  • WarNov Developer Evangelist

    DLLs de VB6 que no trabajan en x64

    • 0 Comments

    Tiene usted una biblioteca que le ha servido por años y que está escrita en el viejo VB6?

    Se ha visto enfrentado a tener que usarla a hora para una aplicación creada con Visual Studio para correrla en 64bits?

    Entonces ha de ser muy probable que cuando la ejecute allí, obtenga un error como:

    Retrieving the COM class factory for component with CLSID {XXXXXXX} failed due to the following error: 80040154.

    Tal vez luego de esto trató por mucho medio de ver que pasaba, pero sin encontrar solución.

    Aquí lo que sucede es que  el código creado en Visual Basic, definitivamente tiene tipos no compatibles con la arquitectura x64.

    Cuando se crean soluciones en Visual Studio, este por defecto las compila con la opción “Active CPU”. Es decir que cuando el JIT compiler pasa el MSIL a lenguaje nativo de máquina, hace la compilación con la arquitectura en la que se está desplegando la solución. 

    Así que cuando una aplicación que tiene referenciada una DLL de VB6 que solo soporta 32bits se ejecuta en x86, ésta se compila y ejecuta correctamente. Pero en bien se pasa a x64, todo pasa a 64 bits. Y como la dll de Visual Basic 6 no soporta esa conversión, por lo tanto se genera el error. (Aún cuando originalmente se haya compilado en una máquina de 32 bits. Recuerden que la opción por defecto es "Active CPU").

    La solución consiste entonces en especificar para cada proyecto que referencie la DLL en cuestión ( y cualquier otra que falle) que la compilación se debe hacer explícitamente a x86. Así aun cuando se corra el código en una máquina de x64, el código final estará en 32 bits y por ende será compatible con la dll.

    Aunque esta es la única solución aparte de tener que migrar todo el código de VB (cosa completamente aconsejable a mediano plazo), ha de tenerse en cuenta que si su aplicación tiene utilidades muy atadas a 64bits (cosa que no creo), entonces estas dejarán de funcionar.

Page 1 of 1 (3 items)