Una de las muchas ventajas de ser reconocido como MVP es la posibilidad de asistir como invitado al macro evento que Microsoft organiza cada año en Bellevue y Redmond. Y mientras el cuerpo aguante y sigamos teniendo la fortuna de pertenecer a este grupo, no hay que perder la ocasión de volver a disfrutar de la experiencia.

Aunque el sólo por el hecho de pasear por el Campus de Microsoft en Redmond ya merece la pena recorrer los cerca de 9.000 kilómetros que nos separan, el Summit es mucho más que eso. Son cientos de sesiones técnicas del más altísimo nivel para ponernos al día de lo que se cuece en la compañía, dar feedback de productos y tener acceso directo a los equipos que están trabajando en ellos.

Son centenares de colegas de profesión y afición (bueno, algunos miles), de todos los países del mundo, y bastante más frikis que tú en muchos casos... y eso que a veces ponemos el listón alto ;D

Es poder conocer en persona a referencias mundiales en las tecnologías y herramientas con las que trabajamos todos los días, y cruzarte por los pasillos con gente a la que sigues y admiras desde hace años. Y como muestra, un botón: imaginad la sorpresa que se llevó Anders Hejlsberg, creador de maravillas como Turbo Pascal, Delphi, C# o TypeScript, al encontrarse por un pasillo a Luis Ruiz, Jorge Serrano y un servidor ;D

Y, por supuesto, el Summit es compartir unos momentos geniales con los amigos a los que sólo se tiene la oportunidad de ver en este tipo de festivales, en el incomparable marco de Seattle, la ciudad esmeralda.

¡Nos vemos a la vuelta!

Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)

.Net

• Inferring from “is”, part one and part two
  Eric Lippert
• Serilog - An Excellent Logging Framework Integrated With .NET Applications
  Andy Feng
• .NET Core and ASP.NET Launches a Beta Bug Bounty Program
  Jeffrey T. Fritz
• Learn Roslyn Now: Part 14 Intro to the Scripting API
  Josh Varty

Está claro que uno de los secretos para la creación de aplicaciones web de alto rendimiento es el uso apropiado del caché, y por esta razón todos los frameworks incorporan herramientas que hacen posible almacenar información que pueda ser reutilizadas para acelerar la respuesta de peticiones posteriores, como porciones de página o resultados de procesos costosos.

En ASP.NET 4.x y anteriores, siempre podíamos acceder a objeto Cache disponible en el contexto de la petición, o a los componentes presentes en System.Web.Caching y crear nuestras soluciones personalizadas, pero realmente MVC no aportaba más ayudas de serie que el filtro [OutputCache]. Su objetivo era cachear el resultado de acciones durante un tiempo determinado y reutilizarlo en peticiones siguientes, lo que era suficiente para muchos escenarios pero complicaba un poco otras necesidades comunes, como el cacheo de porciones de páginas.

Pero antes de continuar, un par de avisos:

• Si aún no sabes lo que es un tag helper, ya estás tardando en leer este post ;)
• ASP.NET se encuentra aún en desarrollo, por lo que parte de lo expuesto a continuación podría variar en la versión final del producto.

Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)

.Net

• Lambda Syntax and Performance
  Bill Wagner
• .NET Big-O Algorithm Complexity Cheat Sheet
  Muhammad Rehan Saeed
• Casts and type parameters do not mix
  Eric Lippert
• Regular Expression Grouping
  Richard Carr
• Using HtmlAgility pack and CssSelectors
  DotNetSteve
• Marking Non-User Code
  Richard Carr

Hace unos días hablamos de los tag helpers, esa interesante novedad de Core MVC  destinada a mejorar la legibilidad de nuestras vistas. Comentamos los que traía de serie el framework, y vimos por encima algunos ejemplos para hacernos una idea.

Hoy vamos a ver en profundidad uno de estos helpers, AnchorTagHelper, cuya misión es facilitarnos la creación de enlaces a controladores/acciones de nuestra aplicación. Para hacer más sencilla su comprensión, lo haremos mediante casos prácticos, y comparando cada ejemplo con la fórmulas que hemos usado tradicionalmente y que seguro conocéis, los helpers HTML.

<warning>ASP.NET aún se encuentra en desarrollo, por lo que detalles de lo que contemos por aquí aún podrían variar en la versión final</warning>

Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)

.Net

• .NET Generics under the hood
  Alexandr Nikitin
• Essential C# 6 Features You Need to Know!
  Michael Crump
• Creating a Genuine Value Object
  Peter Vogel
• .NET Shell Extensions - Adding submenus to Shell Context Menus and dynamically loading context menu
  Sagar Uday Kumar
• C#6: Collection Initializers
  Jeff Yates

Hace bastantes meses, allá por febrero, publiqué el post “Inyección de dependencias en ASP.NET 5”, donde describía el sistema integrado de inyección de dependencias que se estaba construyendo en el que todavía se denominaba ASP.NET 5.

Sin embargo, las cosas han cambiado un poco desde entonces, por lo que he pensado que sería buena idea reeditar el artículo y actualizarlo al momento actual, con la beta 8 de ASP.NET Core a punto de publicarse.

<disclaimer>Aunque el producto está cada vez más estable y completo, aún podrían cambiar cosas antes de la versión definitiva, incluso antes de tener la release candidate en la calle.</disclaimer>

Si no sabes aún lo que es inyección de dependencias, el resto del post te sonará a arameo antiguo. Quizás podrías echar previamente un vistazo a este otro, Desacoplando controladores ASP.NET MVC, paso a paso, que aunque tiene ya algún tiempo, creo que todavía es válido para que podáis ver las ventajas que nos ofrece esta forma de diseñar componentes.

Para los perezosos, podríamos resumir el resto del post con una frase: ASP.NET Core viene construido con inyección de dependencias desde su base, e incluye todas las herramientas necesarias para que los desarrolladores podamos usarla en nuestras aplicaciones de forma directa, en muchos casos sin necesidad de componentes de terceros (principalmente motores de IoC que usábamos hasta ahora). Simplemente, lo que veremos a continuación es cómo utilizar esta característica ;)

Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)

.Net

• Tasks are (still) not threads and async is not parallel
• Pam Lahoud
• Using Roslyn and unit tests to enforce coding guidelines and more
  Filip Woj
• Which Works Faster- Null Coalescing Operator or GetValueOrDefault or Conditional Operator
  Anton Angelov

Desde la creación de MVC, los helpers han sido piezas fundamentales en la composición de nuestras vistas. Llamadas como las habituales Html.ActionLink() o Html.TextBoxFor() nos han permitido durante años crear interfaces de forma sencilla y productiva, pues se trataba de métodos muy reutilizables capaces de ejecutar lógica de presentación y generar bloques de HTML por nosotros (o CSS, o incluso Javascript).

De hecho, los helpers han sido la fórmula recomendada para crear componentes reutilizables de generación de código de marcas en las páginas de nuestras aplicaciones MVC y son muy utilizados tanto por el propio framework como por componentes visuales de terceros. Pero esto no implica que fuera una solución perfecta o exenta de problemas…

Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)

.Net

• Exceptional Edge Cases
  Bill Wagner
• Some Useful Debugging attributes in Dotnet
  Sivaraman Dhamodharan
• Regular Expression Anchors
  Richard Carr
• How to work with generics in C#
  Joydip Kanjilal
• Enabling source code debugging for your NuGet packages with GitLink
  Oren Novotny
• Virtual, Override, new and Abstract keywords
  DotNetForAll
• Roslyn in MonoDevelop/XamarinStudio
  Miguel de Icaza

Desde la llegada de Razor, hace ya bastante tiempo, usamos en ASP.NET MVC el archivo _ViewStart.cshtml de las carpetas de vistas de nuestra aplicación para introducir código de inicialización de éstas. Era un buen lugar para establecer propiedades como el Layout de forma genérica, sin tener que hacerlo en cada una de las vistas que se encontraran por debajo en el árbol de directorios en el que se definía.

En ASP.NET Core MVC 1.0 se le ha unido un compañero llamado _ViewImports.cshtml, cuya finalidad y funcionamiento es parecido al tradicional ViewStart, porque se procesa antes de ejecutar una vista e igualmente afecta a todas las vistas que se encuentren por debajo de este archivo en el árbol de directorios, aunque aporta algunas diferencias bastante interesantes. Comentamos a continuación los aspectos más destacables.

Ahí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes :-)

.Net

• Parsing Microsoft Word document using C#
  Ipinder Suri
• C#6: Support for .NET Framework 2.0 to 4.5
  Jeff Yates
• Local Machine Interprocess Communication with .NET
  Ricardo Peres
• Regular Expression Character Classes
  Richard Carr
• Supporting Options and Arguments in Your dnx Commands
  James Chambers
• Top 15 Underutilized Features of .NET part I & part II
  Anton Angelov

Seguimos hablando de ASP.NET Core y los cambios que traerá para los desarrolladores que ya llevamos tiempo utilizando ASP.NET y MVC, porque esta nueva versión viene cargada de cambios y algunos son realmente rompedores. Hoy nos centraremos en un cambio simple, pero bastante importante, que afecta a la estructura de nuestros proyectos: el raíz del sitio web.

Desde siempre el directorio raíz de un proyecto ASP.NET, ya fuera Web Forms, MVC, Web API o cualquier otro, coincidía con la raíz del sitio web en el servidor, es decir, en nuestros equipos se mezclaban los archivos propios del desarrollo con los contenidos estáticos que se subían posteriormente a los entornos de prueba o producción.

Esto creaba un poco de lío a la hora de publicar los proyectos, porque era fácil que nos dejáramos algo por detrás a la hora de subir las aplicaciones al servidor, o que enviáramos más archivos de la cuenta, como archivos .JS sin compactar/empaquetar, fuentes Typescript, estilos Less o Sass, mapas de símbolos, etc. Obviamente esto podía causar problemas de seguridad, puesto que podíamos dejar al descubierto aspectos sensibles de la aplicación y era necesario establecer configuraciones que evitaran la descarga de dichos archivos (por ejemplo, evitar el acceso a archivos .config).

A partir de ASP.NET Core esto deja de ser así, y la carpeta raíz del proyecto contendrá exclusivamente archivos relativos al desarrollo del mismo: fuentes C#, Javascript, Typescript, Less, Sass, archivos de configuración, etc.

En cambio, los archivos estrictamente necesarios en runtime (imágenes, bundles de scripts y CSS, HTML, etc.) deberán encontrarse en la carpeta “wwwroot” que cuelga del raíz y que podemos observar en la captura de pantalla adjunta con un icono circular.

En otras palabras, una vez despleguemos la carpeta “wwwroot” al servidor, ésta será la raíz del sitio web, por lo que sólo los archivos contenidos en ella serán accesibles.

Esto presenta varios cambios interesantes. En primer lugar, el hecho de separar los archivos útiles en tiempo de desarrollo de los que van a explotación, hace que podamos despreocuparnos de problemas de seguridad citados anteriormente, porque es más difícil que queden expuestos ficheros con información sensible.

En segundo lugar, ahora podremos tener el raíz de nuestro proyecto mejor organizado porque ya no tenemos necesidad de hacer coincidir la estructura del código fuente con la del sitio en funcionamiento. Estructuraremos nuestro código fuente de la forma que más nos convenga para facilitar su creación y mantenimiento, e idearemos una estructura para explotación más acorde con las necesidades en tiempo de ejecución.

Y por último, este nuevo enfoque hace que encajen a la perfección herramientas como Gulp o Grunt, que nos permitirán automatizar tareas como la copia, comprobación, transformación o empaquetado de archivos. Por ejemplo, podemos utilizar Gulp en cada compilación para que se tomen los archivos Javascript de una carpeta determinada del código fuente del proyecto, combinarlos, minimizarlos y copiarlos posteriormente a su ubicación final dentro de “wwwroot”.

¿Y cómo se ve esto en un servidor donde se esté ejecutando el proyecto? Pues la siguiente captura de pantalla muestra el resultado de desplegar una aplicación ASP.NET Core a un servidor, de Azure en este caso.


En la carpeta “Files”, que es donde Azure muestra el contenido físico del espacio donde se guardan los archivos que hemos subido, observamos dos carpetas “approot” y “wwwroot”.

La primera de ellas, “approot”, contiene los paquetes Nuget de componentes usados por la aplicación, los runtimes (DNX, distribuidos también como paquetes Nuget) y algunos archivos de configuración. Adicionalmente, así lo hemos indicado al publicar el proyecto, podemos incluso encontrar el código fuente de la aplicación.

La carpeta “wwwroot”, que es la que actúa como raíz del sitio web, es donde encontramos los archivos estáticos requeridos por el sitio web. No es posible, por tanto, acceder a través de la web a ninguno de los archivos usados en tiempo de diseño.

Es importante tener en cuenta que este comportamiento se aplica también a la ejecución local. Ya sea desde Visual Studio pulsando F5 o Ctrl-F5, o bien desde línea de comandos (por ejemplo, usando el comando “dnx web”), siempre que ejecutemos la aplicación lo estaremos haciendo sobre la carpeta raíz “wwwroot”.

Cómo cambiar el nombre a la carpeta wwwroot

Si no os gusta el nombre “wwwroot” y preferís algo más castizo, sin problema, está previsto ;)


En estos casos lo primero es renombrar físicamente la carpeta “wwwroot” y ponerle el nombre que más nos guste. Tras ello, basta indicar a ASP.NET Core dónde puede encontrar la raíz de la aplicación, que, como otros muchos aspectos de la configuración, se define en el archivo de configuración project.json.

Así, basta con modificar con cualquier editor el valor de la propiedad “webroot” en el archivo project.json y hacerlo coincidir con el nombre que hemos elegido para la carpeta. Si usamos Visual Studio, en pocos segundos veremos el proyecto actualizado:



Publicado en Variable not found.