ASP.NET 5 es ASP.NET Core

Y cuando pensamos que con el tema del versionado ya teníamos suficiente y estaba cerrado, anuncian que ASP.NET 5 ahora es ASP.NET Core… y se reivindican por completo. 🙂

Hace unos días Scott Hanselman anunció en su blog que hubo un “re-nombramiento” en cuanto al versionado del nuevo stack de tecnologías .NET (vNext). Las mismas pasan a llamarse Core y comenzarán desde cero.

Resumiendo:

  • ASP.NET 5 >> ASP.NET Core 1.0.
  • .NET Core 5 >> .NET Core 1.0.
  • Entity Framework 7 >> Entity Framework Core 1.0 or EF Core 1.0 colloquially.
ASP.NET Core 1.0

ASP.NET Core 1.0

Por un lado creo que ahora está más clara la separación entre ambas tecnologías (clásica y nueva) pero por otro lado coincido con José M. Aguilar en que lo hicieron demasiado tarde.

En fin, esperemos que no haya más sorpresas de aquí en adelante.

Pero que mareo con ASP.NET vNext

Hace tiempo que vengo trabajando con ASP.NET, en particular con su framework MVC, y si había algo con lo que estaba conforme era la forma en que se venía lanzando las versiones del mismo. La periodicidad con el que sacaban nuevas versiones permitía conocer “a fondo” el framework y estaba relativamente claro cuales eran las features introducidas como las dependencias con .NET. Estas y otras cosillas nos daban mayor confianza para dar el salto.

Todo bien hasta el anuncio de ASP.NET vNext. De entrada se habló de dos alternativas para trabajar en ASP.NET: la tradicional y una variante que correrá con .NET Core (este último para quien no lo conozca es una versión “ligth”, más rápida y multiplaforma del framework .NET).

Por lo tanto surgen “dos versiones” de nuestro querido framework web:

  • ASP.NET 4.6: sigue el curso “normal” del framework, es decir la misma forma de trabajo que ahora con la clásicas tecnologías ASP.NET MVC, Web API, WebForms, SignalR.
  • ASP.NET 5 o ASP.NET vNext: que esta pensado para trabajar sobre .NET Core y que deja afuera tecnologías como WebForms por ejemplo.

Conclusión, tenemos ASP.NET 4.6 que corre en la versión “completa” de .NET – .NET Full Framework 4.6 – y ASP.NET 5 que correrá en ambas versiones, la versión “full” y la “ligth” de .NET – .NET Core 5 -.

ASP.NET vNext

ASP.NET vNext

Y llegan los dolores de cabeza, porque si trabajamos con MVC en ASP.NET 4.6 estaremos trabajando con ASP.NET MVC 5.x y en cambio si lo hacemos sobre ASP.NET 5 sera ASP.NET MVC 6. Lo mismo pasa con otros frameworks como SignalR, en ASP.NET 4.6 es SignalR2 y en ASP.NET 5 tenemos SignalR3.

No perdamos de vista que ASP.NET 5 esta siendo escrito desde cero para la tecnología .NET Core, por lo que será incompatible con ASP.NET 4.6 y anteriores.

Para quienes no lo tengan presente .NET Full Framework 4.6 se presentó en el lanzamiento de Visual Studio 2015 mientras que la versión Release Candidate de .NET Core 5 estaría a finales de año. Es decir que, ya podemos trabajar con una de las alternativas pero debemos esperar – ¿mucho? – para trabajar con tranquilidad en la otra (y eso que llevan un largo tiempo anunciándolo).

Ahora bien, ¿qué se trae de nuevo ASP.NET MVC 6?. Rápidamente comentarles que tiene una nueva estructura de los proyectos, desaparece el archivo global.asax y aparece la clase Startup, desaparece nuestro viejo y querido web.comnfig y aparecen nuevos archivos de configuración JSON (global.json, bower.json, config.json, package.json y project.json), nuevos folders como “wwwroot”, integración con nuevos gestores de paquetes, desacoplamiento de IIS lo que nos permite tener nuestra aplicación auto hosteada en múltiples plataformas, etc. Pronto estaré escribiendo sobre el tema.

Resumiendo, creo anunciar vNext de forma tan temprana hizo que los desarrolladores nos confundamos más de la cuenta, más aún si tenemos en consideración toda esta tramoya de versiones. Esperemos que con el tiempo todo esto se normalice y haya más novedades al respecto. Mi opinión personal, arrancar con ASP.NET 4.6 y de paso ya ir “jugando” cada vez más con ASP.NET 5 hasta su lanzamiento.

Para mayor información sobre el tema recomiendo absolutamente el siguiente articulo: Descifrando el lío de ASP.NET vNext: versiones, disponibilidad, Visual Studio…

SignalR – Introducción

SignalRHace tiempo que tengo intenciones de comenzar a escribir sobre este tema, pero por una cosa u otra lo fui postergando. Para quienes no lo conozcan, SignalR es un framework de la pila de tecnologías web de Microsoft pensado para la construcción de aplicaciones en tiempo real. Las aplicaciones web con funcionalidad en tiempo real son aquellas que tienen la capacidad de enviar – desde el servidor – notificaciones al instante a los clientes conectados, en lugar de esperar que ellos vuelvan a solicitarlos ya sea por medio de polling o requests.

Ejemplos de este tipo de aplicaciones son los juegos “online” multi-usuarios, herramientas colaborativas como por ejemplo Google Docs u Office Web Apps, servicios de notificaciones en vivo, chats y otros tipos de servicios que actualmente son muy comunes de ver en aplicaciones como Facebook y Twiter.

La definición para SignalR que nos da el sitio oficial es la siguiente:

ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. What is “real-time web” functionality? It’s the ability to have your server-side code push content to the connected clients as it happens, in real-time.

SignalR es el marco de trabajo perfecto para el desarrollo de aplicaciones en Internet que soporten múltiples usuarios colaborando al mismo tiempo.  Y para que esto sea posible nos provee de una API que abstrae al desarrollador de las cuestiones de bajo nivel y nos brinda componentes para ambos extremos de la comunicación – cliente y servidor – tema que ya veremos más adelante.

Es importante saber que es una librería que se monta sobre el stack de tecnologías para la web ASP.NET y se encuentra al mismo nivel de otros frameworks bien conocidos por nosotros como Web API o MVC:

SignalR

SignalR

Como bien lo muestra el gráfico tanto SignalR como Web API están pensados para resolver implementaciones orientadas a servicios mientras que Web Forms y MVC fueron diseñados para la construcción de aplicaciones web.

Siguiendo la movida que implementó Microsoft en los últimos años, SignalR es open source – licencia Apache 2.0 – lo que nos permite estudiar sus fuentes y colaborar a través de GitHub. La versión 1.0 salio en Febrero de 2013 y la versión 2.0 unos meses más tarde en Octubre del mismo año. Al momento de escribir esto se encuentra en la versión 2.2.0 que se lanzo en Enero de este año y es la que utilizaremos en los próximos post.

Para finalizar con esta pequeña introducción contarles que SignalR está siendo utilizado en muchos proyectos reales como ser Web Apps de Office, SkyDrive y Office 365 entre otras, lo que habla de un marco de trabajo estable. Otro ejemplo es el juego Shootr construido en su totalidad con esta tecnología.

En las próximas entregas vamos a contar algunas de las características que hacen de este framework una opción perfecta para la creación de aplicaciones multi-usuarios en tiempo real de una manera realmente sencilla para los desarrolladores.

¡Nos vemos!

One ASP.NET

Para quienes llevan un buen tiempo programando con tecnologías .NET recordaran que aya por el 2001 Microsoft sacaba al mercado algo llamado .NET Framework y acto seguido una nueva tecnología llamada ASP.NET. En aquellos años Internet empezaba a jugar un papel cada vez mas importante y era el momento de entrar en ese mercado. Y ASP.NET fue pensado justamente para atraer a los desarrolladores de aplicaciones de escritorio al desarrollo de páginas-aplicaciones web. Para que el cambio fuese lo mas transparente posible para los developers, ASP.NET adoptó el concepto de WebForms: formularios web donde podíamos arrastrar controles y con un simple “doble click” bindear eventos a los mismos y programarlos en el code behind (una forma de desarrollo muy parecida a la de WinForms).

Luego de un largo tiempo, a principios de 2009, aparece dentro de ASP.NET el patrón MVC y con él ASP.NET MVC 1 (una gran alegría para muchos de los desarrolladores web que esperábamos un cambio en el framework para que sea más orientado a la web!).  A medida que avanzaron los años este framework fue creciendo y con el aparecieron las versiones 2, 3, 4 y recientemente la versión 5.

Pero ASP.NET no solo se conforma de estos dos frameworks (Web Forms y MVC), con los grandes avances en el mundo web, en 2012 se añaden nuevos frameworks a la familia: Web API, SPA y SignalR (tengo pendiente un post sobre el mismo).

Ahora bien, aunque todos forman parte de la familia ASP.NET, generalmente se los suele identificar como proyectos independiente entre sí, sin relación uno con el otro. Esta visión no es correcta y con One ASP.NET se quiere reforzar esta idea.

La idea tras One ASP.NET es tener un único proyecto ASP.NET que podemos customizarlo a partir un conjunto de tecnologías web:

One ASPNET

One ASPNET

Por eso con Visual Studio 2013 cuando vamos a crear un nuevo proyecto web nos vamos a encontrar con una única plantilla “ASP.NET Web Application“:

ASP.NET Web Application

ASP.NET Web Application

Este cambio claramente refuerza el concepto de una única aplicación ASP.NET.

Una vez que creamos el proyecto se nos pedirá que elijamos las tecnologías con las que vamos a trabajar:

Seleccionando las tecnologías ASP.NET con las cuales trabajar.

Seleccionando las tecnologías ASP.NET con las cuales trabajar.

También podemos configurar de forma unificada aspectos como autenticación y testing unitario.

Algunos podrán decir que esto es simplemente un paso “extra” en la selección del template de proyecto a utilizar, sin embargo tras esta idea hay una nueva visión que pretende integrar este conjuntos de tecnologías bajo una única plataforma y finalmente borrar ese concepto que tenemos de proyectos independientes e incompatibles entre sí.

Por último recomiendo el post de José Manuel Alarcon hablando al respecto!

Abrazos!

¡Microsoft MVP 2012 – APS.NET/IIS!

MVP 2012

Hace uno pocos días recibí una noticia que me puso muy feliz y que quería compartirla con todos ustedes: he sido reconocido como Microsoft MVP (Most Value Professional) en el área de ASP.NET/IIS.

Poder pertenecer al mismo grupo del cual forman parte muchos de los profesionales que respeto y admiro, es para mí un gran placer y orgullo. Además quiero agradecer a todos mis compañeros, colegas y familiares que hicieron posible esta distinción.

Para los que no sepan, el reconocimiento como Profesional Más Valioso (MVP), es la forma en la que Microsoft agradece las contribuciones excepcionales realizadas por expertos independientes en la tecnología o los productos de Microsoft al compartir su pasión por la tecnología, su experiencia y su conocimiento con las comunidades técnicas. Pueden encontrar más info acá.

¡Gracias a todos!

ASP.NET MVC : Entendiendo ResponseRedirect

Quienes desarrollamos en algún momento en ASP.NET Webform no necesitábamos tener conocimientos web de bajo nivel ya que los mismos eran abstraídos por el mismo framework. Esto se debía a que ASP.NET, en ese entonces, había sido pensado para atraer a los desarrolladores de aplicaciones de escritorio que se resistían pasar al desarrollo de aplicaciones web. Por lo tanto, la estrategia de MS fue seguir con esa misma filosofía.

En el momento en que uno hace el pase a ASP.NET MVC – cosa que recomiendo a todo desarrollador web de .NET 🙂 – tiene la necesidad de conocer más en profundidad estas cuestiones (HTTP, HTML, CSS…), ya que es parte de la naturaleza del framework y facilita enormemente el desarrollo sobre el mismo.

Como mencione anteriormente, una de las cuestiones web son los protocolos y  hace un tiempo atrás participé de la excelente VAN que presento Leonardo Micheloni sobre HTTP (llamada “HTTP y las ruedas de la web“) donde uno de los tema que toco fueron los distintos códigos de estado que provee este protocolo.

Para quienes no conozcan demasiado de este tema cuando uno hace una petición por medio de una URL se inicia una transacción desde el cliente que termina con una respuesta del servidor que generalmente viene compuesta por el recurso solicitado (sea un HTML, XML…). Uno de los datos que viajan en el encabezado de la respuesta es el código de estado (de los cuales los más conocidos son 200 OK o 404 NOT FOUND).

Estos códigos de estado se encuentran agrupados según su función y uno de esos grupos corresponden a las Redirecciones : 3xx.

Todo esto me hizo pensar en como funcionaba realmente el método RedirectToAction que nos provee la clase Controller de ASP.NET MVC.  Y mis sospecha – no demasiadas brillantes – eran ciertas, la solicitud a una vista que utiliza RedirectToAction retorna HTTP Code Status 302.

Antes de continuar, veamos un poco más en profundidad, de que se trata el código 302 viendo una definición de Wikipedia:

Este es el código de redirección más popular, pero también un ejemplo de las prácticas de la industria contradiciendo el estándar. La especificación HTTP/1.0 (RFC 1945) requería que el cliente realizara una redirección temporal (la frase descriptiva original fue “Moved Temporarily”), pero los navegadores populares lo implementaron como 303 See Other. Por tanto, HTTP/1.1 añadió códigos de estado 303 y 307 para eliminar la ambigüedad entre ambos comportamientos. Sin embargo, la mayoría de aplicaciones web y bibliotecas de desarrollo aún utilizan el código de respuesta 302 como si fuera el 303.

Luego de esta larga introducción, vayamos al grano y definamos dos vistas, la primera la llamaremos Index y la segunda Final. Lo que hará la primer vista será simplemente redireccionar a la segunda:

1: public class HomeController : Controller
2: {
3:     public ActionResult Index()
4:     {
5:         return RedirectToAction("Final");
6:     }
7:
8:     public ActionResult Final()
9:     {
10:         return View();
11:     }
12: }

Ejecutemos y analicemos la respuesta del servidor:

Respuesta HTTP

Respuesta HTTP

Vemos que la petición GET a la URL “http://localhost…/Index” retorna el código 302 Found, y seguido se hace una nueva petición a “http://localhost…/Final” que finalmente es devuelta exitosamente (retornando el código 2oo OK).

Para saber donde tiene que hacer la redirección, uno de los datos que viajan en el encabezado de la respuesta es Location el cual contiene dicha información:

Encabezado de la respuesta HTTP

Encabezado de la respuesta HTTP

Es importante que entendamos como funcionan estas cuestiones, que si bien son simples, uno muchas veces las desconoce pensando que todo es resuelto “magicamente” por el framework.

Espero que les haya sido de utilidad.

Instalando ASP.NET MVC 3

En este primer post sobre la nueva versión de ASP.NET MVC (actualmente en la fase Beta) vamos a explicar de forma sencilla cuales son los pasos necesarios para realizar la instalación.

Antes de avanzar debemos validar los requerimientos necesarios: .NET 4, ASP.NET 4, Visual Studio 2010 o Visual Web Developer 2010.  Windows 7, Windows Server 2003, Windows Server 2008 o Windows Vista.

Validado esto, vamos a descargar el archivo instalador – AspNetMVC3Setup.exe – desde aquí. Bajamos, ejecutamos y comenzamos con la instalación, la cual no tiene demasiados secretos.

Puede que les aparezca el siguiente mensaje de error “This product requires Microsoft ASP.NET Web Pages 1.0. Please install the missing component, then try to install this product again.”.

Error durante la instalación

Error durante la instalación

Para solucionar esto lo que debemos hacer es descargar de la misma página el instalador de ASP.NET Web Pages 1.0AspNetWebPages.msi – ejecutarlo y nuevamente iniciar la instalación de ASP.NET MVC 3.0.

Finalizados todos estos pasos abrimos Visual Studio y veremos que ya podemos crear nuestras aplicaciones web ASP.NET MVC 3!

Proyecto del tipo Aplicación Web ASP.NET MVC 3.0

Proyecto del tipo Aplicación Web ASP.NET MVC 3.0

En próximos posts vamos a estar hablando de las nuevas características que nos trae esta nueva versión del framework.