Una novedad que descubro en los tutoriales preliminares de la segunda versión de WebPages, y que por tanto tendremos disponible en las futuras versiones de WebMatrix y ASP.NET MVC 4, es la posibilidad de registrar los scripts y estilos que necesitan nuestros componentes visuales (sean layouts, vistas completas, parciales o helpers), centralizando su carga y evitando duplicidades.
Por ejemplo, imaginad que tenemos una vista parcial o helper que requiere la inclusión de una biblioteca de scripts concreta. Si introducimos los correspondientes tags <script>, y por cualquier causa necesitamos utilizar este componente más de una vez sobre la misma página, estaremos realizando una doble carga del archivo externo, lo que además de lento puede generar errores. Otros escenarios igualmente incómodos son cuando si hay varias parciales distintas que usan una misma biblioteca común, o cuando queremos generar los scripts en un lugar determinado del HTML (por ejemplo, al final de la página) también desde una vista parcial o un helper. Y por supuesto, lo mismo ocurre con los estilos CSS.
El Asset Manager es un componente introducido en WebPages 2, también disponible para MVC 4, que va a poner un poco de orden ahí, usando un mecanismo bastante parecido al disponible en Webforms desde hace bastante tiempo.
Así, el objeto estático Asset (definido en System.Web.WebPages) permite registrar bloques de script inline, referencias a archivos de script externos, bloques de estilos, y referencias a archivos de hojas de estilo usando métodos tan simples como los siguientes:
Assets.AddScriptBlock("alert('hi!');", true); // Include <script> tag
Assets.AddScript("~/scripts/jquery.1.6.2.js");
Assets.AddScript("~/scripts/jquery.1.6.2.js");
Assets.AddStyleBlock("p { font-size: 4em}", true); // Include <style> tag
Assets.AddStyle("~/content/site.css");
Este registro se puede implementar en cualquier parte dentro del ciclo de ejecución de la vista: en la página de contenido, parciales, helpers, de forma que se irán registrando todos los elementos que puedan hacer falta. Más adelante, para generar los bloques almacenados basta, con hacer lo siguiente por ejemplo en el Layout:
[...] </div> </div> </footer> @Assets.GetScripts() </body> </html>
El resultado en ejecución sería:
[...] </div> </div> </footer> <script type="text/javascript">alert('hi!');</script> <script src="/scripts/jquery.1.6.2.js" type="text/javascript"></script> </body> </html>
Y de la misma forma, tenemos disponible un método @Assets.GetStyles() para obtener todos los bloques relativos a estilos de la página que hemos ido registrando, y que podríamos generar en el interior de la etiqueta <head>, por ejemplo.
Es interesante saber que, al generar el código, Asset detectará si existen dos referencias hacia el mismo archivo de script o estilos, en cuyo caso la referencia se generará sobre la página una única vez, aunque por razones obvias este control no se realizará sobre los bloques de scripts o estilos inline.
Publicado en: Variable not found.
El código fuente de la primera versión de ASP.NET MVC fue publicado en 2009, poco después de su lanzamiento, bajo 
Y recalco aquí la palabra “contribuyentes”, que es el segundo aspecto importante de la noticia a la que hacía referencia. No hablamos ya exclusivamente de los equipos de Microsoft que hasta ahora han llevado las riendas: a partir de ahora, los desarrolladores de la comunidad podemos contribuir con parches e implementando funcionalidades de estos tres productos.
Lo divertido de escribir sobre productos que están todavía en fase de desarrollo es que cambian… y a veces, ¡de qué forma! Pues esto ha ocurrido con SignalR: recientemente se 
Mediante la invocación a 
Pues sí, toda una experiencia, no podría describir de otra forma los días que acabo de dejar atrás. Aún con las avenidas de Bellevue grabadas en la retina, el regustillo amargo de la cerveza Mac&Jac en el paladar, y el aroma a la Kobe Burger del Cheesecake Factory, es un buen momento para hacer una breve retrospectiva de lo que ha sido este viaje.
Sin tener en cuenta los días que hemos ocupado por completo viajando, han sido en total cinco días de estancia en Bellevue, lo que nos ha dejado tiempo para todo: turismo, sesiones técnicas, networking, compras, divertirnos en buena compañía, y saludar a personas a las que no había tenido oportunidad de conocer hasta este momento.
Seguro que todos sabéis lo que es tratar con los usuarios de vuestro software: son lentos, patosos, inconscientes, atrevidos, inseguros, ignorantes, y no consiguen entender la belleza de la herramienta que con tanto esmero hemos creado. Y lo que más rabia da es que muchas veces tienen razón en los problemas que reportan de nuestras aplicaciones.
Bueno, supongo que ya os habréis enterado, pero por si acaso os lo comento: varios meses después de aparecer la última revisión pública, hoy mismo 
También en la carpeta de vistas encontramos los siguientes archivos:
Habitualmente asociamos la validación de entidades basadas en anotaciones de datos, o data annotations, a tecnologías como dynamic data o ASP.NET MVC, y estamos acostumbrados a que la validación se realice de forma automática, pero nada más lejos de la realidad. Podemos utilizar data annotations desde cualquier tipo de aplicación .NET (Webforms, Winforms, WPF, Consola, o cualquier otra en la que tengamos disponible 
Bueno, pues vamos al tema: emplearemos esta vía para implementar una funcionalidad bastante simple, pero nada trivial utilizando las herramientas habituales de ASP.NET: mostrar en una página, en tiempo real, información sobre los usuarios que están llegando a ella, los que la abandonan y el número de usuarios que hay conectados justo en ese momento, en tiempo real. 
Una aplicación que mezcla internet, asincronía, y múltiples usuarios colaborando e interactuando al mismo tiempo siempre es merecedora de un “¡uau!”. Seguro que, al igual que un servidor, en algún momento os habéis quedado maravillados con la interactividad que presentan algunos sistemas web modernos, como Facebook, Google Docs, o muchos otros, en las que estamos recibiendo actualizaciones, prácticamente en tiempo real, sin necesidad de recargar la página.
A priori, no hay forma de que el servidor sea el que notifique a los clientes los cambios de estado (por ejemplo, la llegada en un chat de un mensaje procedente de otro usuario), salvo que éstos utilicen un mecanismo de polling, es decir, que estén continuamente estableciendo conexiones con el servidor para ver si hay algún nuevo evento a tener en cuenta. 
Sin embargo, hasta ahora esto sólo se podía conseguir usando sockets, lo cual, en entorno web, requería la existencia de algún tipo de elemento activo sobre la página (Silverlight, Flash, o applets Java, por ejemplo) capaz de establecer este tipo de comunicaciones.
Por ejemplo, el mecanismo long polling utiliza peticiones HTTP para crear una conexión “pseudopersistente”. El servidor, en lugar de procesar la petición y retornar la respuesta de forma inmediata, espera hasta que haya disponible algún evento o mensaje a enviar al cliente; en este momento, lo retorna como respuesta a la petición original y cierra la conexión. El cliente, por su parte, procesa esta respuesta y realiza inmediatamente después una nueva petición al servidor, que volverá a quedar abierta a la espera de mensajes, y así sucesivamente.
Debido a ello, y para asegurar la máxima compatibilidad con los clientes, actualmente se utiliza por defecto el transporte denominado Long polling, que ya hemos comentado anteriormente.