Mañana, dia 31 de octubre, se celebrará en la universidad de Deusto, el siguiente evento del grupo de usuarios del País Vasco.
Esta vez será Oscar Alvarez el encargado de hacernos una famulosa presentación de Silverlight.
Si estáis interesados os podéis registrar aquí.
19:00 Registro
19:15 SilverLight
Que es SilverLight?
Viendo XAML
Silverlight 1.0
Comparacion entre 1.0 and 1.1
Silverlight 1.1
…Una mirada al futuro
El grupo de usuarios BcnDev.Net ha preparado un concurso bastante interesante sobre Silverlight.
El concurso, a parte del reto personal que puede suponer, tiene premios bastante interesantes. El primer premio es un viaje al Mix de las Vegas en Marzo de 2008, con todos los gastos pagados ( viaje y estancia ). Pedazo premio!!!
Si queréis ver toda la información sobre el concurso podéis pinchar aqui. Merece la pena!!
El pasado 3 de octubre celebramos en Bilbao el evento «Exprime tus datos con SQL Server 2005 Reporting Services!!». Acudió bastante gente, unas 50, y aunque alguna demo se puso un poco tonta en general todo salió bien, o al menos eso intentamos.
Por si alguien está interesado, pongo las ppts y demos que se utilizaron.
En un post anterior ya comentaba que en Windows Communication Foundation ( WCF ) no es oro todo lo que reluce y algunas cosas me hacen reafirmarme en mi opinión. Hace poco tuvimos un «problema» con WCF que me dejó bastante contrariado. A continuación intentaré explicar lo que pasó.
Haciendo unas pruebas de carga sobre la aplicación web que estamos desarrollando nos dimos cuenta de que el rendimiento de la aplicación era bastante malo, porque cada vez que hacíamos una petición al servidor se lanzaba el compilador, el proceso csc.exe. Lógicamente, el rendimiento era malísimo porque el proceso csc.exe se quedaba con gran parte de la CPU, lo que hacía que se procesasen muy pocas peticiones.
Pero..¿ Por qué se lanza el compilador ? ¿ Qué sentido tiene ? En una versión release no le veo sentido por ningún lado….pero sí, sí tiene sentido.Y el sentido está en que usamos comunicación wcf entre la consola web y la lógica de negocio y en que en muchos casos se usan DataSets.
Cuando el cliente WCF genera el proxy para llamar al servidor automáticamente se crean clases con el atributo XmlSerializer para poder llamar al servidor.
El cliente, en tiempo de ejecución, por cada tipo de datos que es serializable y que usa XmlSerializer genera y compila código para serializarlo, lo que puede provocar un decremento importante en el rendimiento de la aplicación….y de hecho, eso está provocando.
Por tanto, aunque a nosotros se nos ha manifestado por usar DataSets, podría darse siempre que se usen tipo serializables con XmlSerializer.
Pero todo tiene solución y se puede cambiar este comportamiento y así evitar que se lance el compilador. La herramienta svcutil nos pérmite mejorar el rendimiento de nuestra aplicación generando el código de serialización necesario para nuestros tipos serializables evitando que esta operación se haga en tiempo de ejecución.
La secuencia a seguir es la siguiente:
Y ya está, ya no se vuelve a volver a ver el proceso csc.exe.
Como he comentado antes, esta situación podría darse en otras situaciones que no tengan nada que ver con los proxys wcf. Para estas situaciones existe otra utilidad llamada sgen.exe, que permite obtener la misma funcionalidad que hemos comentado, con la salvedad de que sgen ya genera directamente el assembly necesario para la serialización y no sólo el código fuente.
Para finalizar, comentar que aunque sea una situación normal la que he comentado, me parece bastante absurdo que sea una comportamiento por defecto. Esto sí que sigo sin entenderlo….