La cuenta regresiva para Visual Studio 2010

Es oficial, Visual Studio 2010 saldrá a la luz el 22 de Marzo del 2010, la cuenta regresiva ha comenzado, ahora que el beta 2 ha sido liberado para todos nosotros los pobres diablos no subscriptores de MSDN.

Habilitar Assembly Caching en Silverlight 3

Una de las muchas nuevas caracteristicas de Silverlight 3, es la posibildad de habilitar la caracteristica Assembly Caching, la cual nos permite indicarle al navegador que cargue los ensamblados que nuesta aplicación necesita (archivo .xap) bajo demanda y no todos al cargar la página, como funcionaba en la versión 2.0.

Para lograr esto, solo debe seleccionarse la opción “Reduce XAP size by using appication library caching”, en el apartado de propiedades de nuestro proyecto Silverlight. También debemos notar como ahora se crean archivos con extensión.zip para cada uno de los ensamblados que la aplicación ocupa y que serán descargados bajo demanda.  Como se puede observar a continuación:

Cuando la opción no es seleccionada, el archivo resultante xap, es más grande que cuando la opción es seleccionada. Como se puede ver en las siguientes imágenes comparativas.

Opción NO habilitada

Opción habilitada

Pongamos especial atención en el archivo AppManifest.xaml y la sección Deployment.ExternalPart, en la cual se indica cuales son los ensamblados que nuestra aplicación referencia y que serán descargados cuando así se requiera, estos son los ensamblados “cacheados”. Sin embargo noten que hay algunos ensamblados que no son marcados para ser cacheados, como: CachedAssembly.dll o los ensamblados del silverlight toolkit.

Para que esto suceda se debe crear el archivo XXXX.extmap.xml. Y después de crearlo recompilar el proyecto, y automáticamente se creara el archivo XXXX.zip, el cual será copiado a la carpeta ClientBin de la aplicación ASP.Net.  Para facilitar un poco esto, puedes ocupar la utilería Emm, la cual crea automáticamente el archivo XXXX.extmap.xml a partir de tu ensamblado ejecutando un comando como el siguiente:

Nota, para el correcto funcionamiento de esta utilería, el ensamblado debe tener un SN (strong name)

Además también se puede usar para los ensamblados del Silverlight Toolkit, de esta forma solo se descargaría en primera instancia nuestro ensamblado y todos los demás ensambados seria descargados “on demand”. Ejemplo:


En resumen, esta característica es muy poderosa para el mejor desempeño de tus aplicaciones silverlight.

Descargar solución de Ejemplo

Happy Coding!

Silverlight Toolkit Octubre 2009

Ya está disponible la última actualización del silverlight toolkit de Octubre del 2009, y como en cada release, esta versión nos trae nuevas y llamativas funcionalidades, y esta no se podía quedar atrás. Las nuevas características, por mencionar algunas:

• Soporte para Visual Studio 2010, que por cierto se acaba de liberar el día de ayer la beta 2.
• Todas las clases base del namespace Data Visualization han sido “unsealed”, es decir, ya es posible heredar de ellas y así extender su funcionalidad.
• La interface ISeries ahora es la interface base de todos los tipos de series para las graficas.
• Se ha agregado el assembly System.Windows.Controls.Data.Toolkit y el assembly System.Reactive
• Soporte para Drag and Drop para elementos tales ListBox, TreeView, DataGrid y DataPointSeries.

A continuación una pequeña demostración de esta última característica, realmente es muy fácil su uso y es mucho el valor que agrega a nuestros desarrollos.

Aquí algunos recursos de donde pueden profundizar en el tema:
Silverlight Toolkit de Octubre 2009
Drag and Drop Support

De aquí pueden descargar el código completo.

Happy Coding!

Establecer el host-header de una web application con https binding en IIS 7

Expondré un escenario que nos ocurrió hace poco en una implementación de SharePoint:

Creamos una nueva SharePoint web application, de la forma que ya conocemos, esta web application llamada SecureWebApplication, usara ssl y vivirá en el puerto 80, por lo que la url que da de la siguiente forma: https://securewebaaplication. Al crear esta web application le asignamos un host header, ya que conocemos previamente de la existencia de otra aplicación que se está ejecutando en este puerto.

Después de que la creación de la web application y site collection se llevaron a cabo satisfactoriamente, nos percatamos que la web application no responde, vamos al IIS y encontramos con que el sitio está detenido, intentamos iniciarlo, pero aparece un mensaje indicándonos que existe otro sitio que se encuentra utilizando el mismo puerto.

Efectivamente, existen otros sitios que se encuentra en el puerto 80, pero con host-headers diferentes, entonces, ¿por qué no puede iniciar nuestro sitio web?

Un poco de aburrida teoría…

Existen tres datos que definen la unicidad de un sitio web, los cuales son:

• Dirección IP
• Puerto
• Host name (host-header)

A la suma de estos tres datos se le conoce como binding,  y define a un sitio web que escucha en una ip:puerto con un host-header especifico.

Cuando se recibe una petición, el componente HTTP.sys lee las propiedades de  configuración del sitio al cual se hace la petición, tales como: tiempo de timeout, limite de conexiones y el certificado que utiliza el sitio

Pero para saber a qué sitio se está haciendo la petición, HTTP.sys utiliza el binding (los tres componentes arriba mencionados),  recordemos que el certificado es necesario para desencriptar los datos encriptados que el cliente envía (en donde viene el host-header)

O sea, que tenemos una dependencia circular. Por una parte necesitamos el certificado para desencriptar la información enviada y de ahí recuperar el binding para a su vez poder leer las propiedades de configuración. Y por otro lado necesitamos primero leer las propiedades de configuración para obtener el certificado y así desencriptar la información que viene del cliente. WTF!

En IIS 7, cuando nosotros creamos un binding https en un sitio web,  este automáticamente deshabilita el que nosotros podamos escribir el host-header, porque el host-header esta embebido en el certificado

 





Y después de toda esta reseña, la solución a esto es una pequeña utilería que se encuentra en la carpeta %windir%\system32\inetsrv, llamada appcmd, con la cual podemos forzar a que el host-header del https binding sea establecido. Con algo más o menos asi:

appcmd.exe set site /site.name:securewebaaplication /bindings.[protocol='https',bindingInformation='*:443:'].bindingInformation:*:443:securewebaaplication

Y el resultado final

Pueden revisar este enlace, para mas detalles.