El servicio de persistencia de Windows Workflow Foundation

Hace ya bastante tiempo que llevo jugando con WF, puesto que lo necesitaba por exigencias de trabajo, incluso con herramientas ya realizadas sobre versiones beta, tengo que decir que es un tema que me encanta ya que me parece chulísimo todo lo que podemos hacer y como está montado el marco de trabajo, de hecho prepararé un fabuloso curso de WF para CampusMVP que seguro que para los que os apuntéis, os animo desde aquí, os gustará. El caso es que voy a tratar de dar una charlita un poco avanzada sobre WF en un evento de Microsoft para MVP dentro de poco y quería hablar de algo que me parece muy importante como es el servicio de persistencia de WF. Revisando notas propias y alguna información me encontré con un post un poco ‘chungo’ afirmando que el servicio de persistencia era un jueguete, el post es este. La verdad es que se pasó un poco haciendo esta afirmación, de hecho no constató sus palabras y este tipo de cosas suelen tener su respuesta, como la de Paul Andrew, del equipo de WF, que no tardó mucho en darle un pequeño tirón de orejas, no se cuanto de pequeño o de grande J y que relata el porqué del servicio de persistencia… sin duda muy interesante leerlo….


Saludos


Unai Zorrilla Castro

Windows Mobile 5.0 y MSMQ

Llevo un par de dias urgando en la versión de MSMQ para dispositivos móviles preparando una maravillosa parte para los cursos de certificación de CampusMVP, que espero sean del agrado de los asistentes. Ya había jugado con este tema desde las versiones beta de Compact Framework 2.0 e incluso había publicado un artículo en MTJ.NET. Revisando blogs y más blogs sobre este tema en busca de algún detalle que se me pudiera estar escapando y que fuera interesante como material para el curso observaba bastantes cuestiones acerca de un error en la instalación de MSMQ que voy a pasar a comentar.


En principio se suelen usar dos formas, una variante de la otra, para instalar MSMQ en los dispositivos, la primera es llevarse el archivo de empaquetado msmq.cab, que podremos encontrar en los ‘Optional Windows Mobile 5 Server Componentes’ y proceder a su instalación, con esto conseguimos llevar las librerías y herramientas como msmqadm.exe y visadm.exe  a los directorios apropiados, posteriormente tendríamos que ejecutar visadm.exe y los comandos necesarios para proceder al registro de MSMQ. La segunda versión de instalación consiste en establecer estas librerías y herramientas como archivos incluídos en el proyecto y como ‘Copy To Output Allways’ . es decir, que acompañen a nuestra aplicación, para posteriormente desde código copiarlas a los directorios específicos, en este caso Windows. Hasta este punto nada fuera de lo normal, sin embargo existe un paso a realizar en ambos casos y consiste en registrar el driver de MSMQ y es aquí dónde viene el misterioso problema. Para registrar el driver de MSMQ realizamos una llamada a nativo tal y como vemos a continuación:


IntPtr handle = ActivateDevice(MSMQ_DRIVER_REG, 0);


                    CloseHandle(handle);


                    if (CreateProcess(MSMQ_ADM, “status”))


                        MessageBox.Show(“MSMQ running”);


                    else


                        MessageBox.Show(“System Error = “ + GetLastError().ToString());


Tal y como decía el problema que se repite en multitud de foros y blogs como los anteriormente propuestos hace referencia a que este registro de driver que acabamos de ver funciona correctamente en los emuladores de Windows Mobile 5.0 pero no en los dispositivos reales y en la consola de visadm.exe siempre encontramos un maravilloso y explicativo código de error, el error C00E000B  ¿ Cual es el problema y cual es la solución ?


Despues de darle muchas vueltas y hablar con mi compañero y amigo Alejandro Mezcua comentamos que podría ser algún tipo de problema de seguridad puesto que el driver esta firmado con un certificado no presente en el Root de los dispositivos por lo que lo exportamos y lo incluímos, el problema es que seguía sin funcionar…. Alejandro se dió cuenta de un problema que le había pasado en el registro de un Driver que el se había construído y sugirió hacer el registro del driver en WindowsStartUp y !!!!!voila!!!!!!


 Realmente el problema es que Windows Mobile no permite el registro de un nuevo driver en User Mode por lo que el código visto nunca funcionará a lo menos que lo ejecutemos en la carga del S.O.


 


Espero que os haya gustado y que no perdais mucho tiempo con el maravilloso C00E000B..


 


Saludos


Unai Zorrilla Castro

Visual Studio Orcas y el testeo unitario para dispositivos móviles

En otro post ya había comentado la posiblidad de realizar Unit Test para nuestros desarrollos sobre dispositivos móviles con Mobile Client Software Factories, ahora según leo en el blog de Visual Studio for Devices se podrá realizar de la misma sencilla forma que en los desarrollos para WinForms puesto que existirá la posiblidad de crear proyectos de UnitTest para Smart Devices. Sin duda esto es una excelente noticia ya que para los que realizamos estos procesos nos sentiremos mucho más ágiles al contar con una herramienta integrada dentro del propio entorno de desarrollo.

 Podeis encontrar más información aqui

Saludos

Unai Zorrilla Castro