Mostrando entradas con la etiqueta novedades. Mostrar todas las entradas
Mostrando entradas con la etiqueta novedades. Mostrar todas las entradas
martes, 24 de mayo de 2016
Como sabéis, hace unos días se lanzaron las respectivas versiones Release Candidate 2 de .NET Core y los frameworks ASP.NET Core y EF Core.Los detalles ya los comentamos en un post anterior, ahora vamos a centrarnos en ver algunos cambios importantes que llaman la atención cuando empezamos a jugar con esta nueva entrega de ASP.NET Core.
lunes, 9 de mayo de 2016
Hace un par de días, Scott Hunter, Program Manager de .NET en Microsoft, desvelaba las fechas de aparición y otros detalles sobre las próximas releases de ASP.NET Core, de las que no teníamos noticias desde el pasado mes de febrero, momento en que decidieron retrasar los lanzamientos previstos.
Veamos cómo queda ahora la cosa.
martes, 9 de febrero de 2016
Pues a estas alturas, no son pocos los posts que hemos ido publicado por aquí sobre características que cambian o desaparecen en el salto a las nuevas tecnologías "core", pero no se vayan todavía, aún hay más ;)En esta ocasión, comentaremos muy brevemente una gran ausencia en las vistas Razor: la directiva
@helper, que no estará disponible en la primera versión de ASP.NET Core MVC.<Disclaimer>Aunque en una Release Candidate las cosas no deberían cambiar, ya han demostrado bastantes veces que sí que cambian, por lo que algo de lo que digamos aquí podría no ser cierto en la versión final del producto</Disclaimer>
Esto no es un tema reciente: hace ya bastantes meses, la implementación que había era bastante incompleta y no encajaba bien en la nueva arquitectura, por lo que tras algunos debates y reuniones de diseño, se decidió que lo mejor era eliminar esta directiva.
martes, 29 de septiembre de 2015
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…
martes, 22 de septiembre de 2015
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.
martes, 21 de abril de 2015
Seguro que ya todos conocéis la fórmula mágica mediante la cual podemos activar la compilación de vistas en versiones de ASP.NET MVC anteriores a la 6. Los que no sepáis de qué os hablo, podéis echar un vistazo a este vídeo que publiqué en el blog de CampusMVP hace algún tiempo: VIDEO: Activar la compilación de vistas en ASP.NET MVC.
Muy resumidamente, el asunto consistía en editar manualmente el archivo de proyecto de Visual Studio, con extensión .csproj, y establecer el contenido del tag <MvcBuildViews> a true.
martes, 10 de marzo de 2015
Hemos comentado en algunas ocasiones que, aparte de la entrada de ASP.NET Core y los cambios en la infraestructura que ello implica, el nuevo MVC incluye también algunas novedades bastante interesantes. Ya estuvimos viendo hace algún tiempo los filtros asíncronos, y hoy vamos a centrarnos en una nueva directiva que podremos utilizar en nuestras vistas Razor a partir de la llegada de la próxima versión del framework.La novedad en cuestión consiste en la capacidad de añadir a las vistas propiedades cuyo contenido será cargado en tiempo de ejecución usando el motor de inyección de dependencias de ASP.NET 5. o dicho de otra forma, se trata de una implementación de inyección de dependencias en las vistas, componentes en los que hasta ahora eso no era posible, al menos de forma directa y sencilla.
Vamos a verlo en detalle, pero antes, recordad: a día de hoy ASP.NET Core MVC sigue todavía en el horno, y puede que algunas de las cosas que cuente por aquí no sean del todo ciertas para la versión final.
martes, 24 de febrero de 2015
Nota [05/10/2015] - Hay una versión actualizada de este post.
La inyección de dependencias ha sido un tema recurrente en Variable not found desde hace bastante tiempo, y dadas las grandes novedades incluidas en ASP.NET 5 al respecto estaba deseando hincarle el diente y publicar algo sobre el tema.Para los perezosos, podríamos resumir el resto del post con una frase: ASP.NET 5 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 ;)
Pero permitidme una nota antes de empezar: 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.
Ah, y recordad: todo lo que vamos a ver podría cambiar conforme vaya avanzando el desarrollo del producto, pero más o menos son cosas que parecen relativamente estables desde hace algún tiempo.
martes, 17 de febrero de 2015
Hace sólo unos días comentábamos la próxima desaparición del Global.asax a partir de ASP.NET Core y su sustitución por la clase StartupY en esta ocasión hablaremos sobre la desaparición del Web.config, el célebre archivo de configuración que lleva con nosotros desde los inicios de ASP.NET. Nacido en momentos en que se pensaba que XML era la panacea y muy ligado al denostado System.Web, ha sido útil durante años para configurar aspectos relativos a la compilación y ejecución de las aplicaciones web en el servidor, así como el “sitio oficial” para introducir de settings como cadenas de conexión y otros valores configurables de nuestros sistemas.
Pero, antes de continuar, un disclaimer: ASP.NET Core está aún en desarrollo, y parte de lo que se diga aquí puede no ser del todo cierto mañana mismo, aunque posiblemente los conceptos fundamentales sí lo serán. O eso espero ;)
martes, 10 de febrero de 2015
Hace poco hablábamos del destierro del Global.asax en ASP.NET Core, y de cómo la clase Startup, siguiendo la convención establecida por este framework, era el lugar elegido para introducir código de inicialización.Pero además del código personalizado que podamos introducir, es donde, por defecto, se configuran aspectos tan importantes como los middlewares que guiarán el proceso de las peticiones, o la inyección de dependencias incluida de serie en el framework.
En este post vamos a estudiar un poco más a fondo la clase de inicialización de ASP.NET Core, y comenzaremos viendo qué vamos a encontrar en ella, y las convenciones a las que hay que ceñirse para que el entorno pueda inicializarse correctamente.
martes, 3 de febrero de 2015
El célebre Global.asax ha estado con nosotros durante más de diez años, y, junto con el Web.config y algunos otros, ha sido uno de los archivos que encontrábamos siempre en la carpeta raíz de toda aplicación web basada en ASP.NET.Durante lustros lo hemos usado para introducir código de inicialización de nuestras aplicaciones y para tomar el control en distintos momentos del proceso de las peticiones: al recibirse una solicitud, al retornar la respuesta, al comenzar una sesión, al finalizarla, al autenticar las peticiones… en fin, que es fácil echarlo de menos cuando abrimos o creamos nuestra primera aplicación ASP.NET Core.
Pero como ya hemos comentado por aquí en alguna ocasión, con ASP.NET Core nuestro entrañable Global.asax desaparece para no volver, en primer lugar porque la propia clase
HttpApplication, donde se originan esos eventos en los que introducíamos nuestro código, es parte inseparable de System.Web, y ya sabemos que uno de los principales objetivos de ASP.NET Core es desligarse por completo de este pesado lastre. Pero hay algunos motivos estructurales más, que veremos a continuación.
domingo, 28 de diciembre de 2014
Por mi trabajo, suelo “husmear” en el código de muchas aplicaciones creadas por equipos de trabajo en empresas de todo tipo y nacionalidad, y os puedo asegurar que existe un denominador común en todas ellas y que seguro reconoceréis en vuestro propio código: los desarrolladores escribimos como nos viene en gana.No es poco frecuente ver aplicaciones con faltas de ortografía que un niño de primaria calificaría como graves. Y notad que no hablo sólo de las etiquetas, mensajes y otros elementos visuales que van a parar a los atónitos ojos de nuestros usuarios, sino también de lo que hay por detrás, en el código fuente.
A nivel de código, las denominaciones internas en clases, métodos o variables, textos en comentarios o incluso los mensajes en check-ins en el control de código fuente, son habitualmente terribles. Claro, sabemos que eso no lo va a leer nadie, o al menos nadie de fuera de nuestro entorno, y bajamos la guardia hasta límites que rozan la ilegalidad. Mezclamos idiomas sin ningún criterio (¿quién no ha escrito alguna vez un método
GetFacturas(), obtenerResources () o una variable lineasCount en su base de código?), cometemos atropellos ortográficos, gramaticales y otros tipos de aberración de forma impune, escudados en que no hay que prestar atención a esos detalles porque es sólo código.Y lo peor es que esta actitud de desidia es contagiosa. Cuando entras en un proyecto donde todo está escrito sin ningún tipo de miramiento, lo normal es que continúes en esa línea, haciendo que la barbarie sea cada vez mayor y, a su vez, más contagiosa en el futuro. Y cuando comiences otro proyecto, llevarás la costumbre de hacerlo así y continuarás extendiendo esta práctica ad eternum.
Pero, ah, amigos artesanos del código, esto se va a acabar.
Las próximas versiones de Visual Studio corregirán drásticamente esta tendencia, incluyendo la revisión ortográfica como parte del proceso de compilación. Además, como comentó S. Somasegar en una reciente entrevista,
“esta característica no podrá ser deshabilitada; en caso contrario ya sabemos lo que ocurriría, y va en contra de la firme apuesta de Microsoft hacia un mundo que se comunique mejor”Y la cosa va muy en serio. Para dar mayor formalidad a esta necesaria iniciativa, Microsoft ha firmado un acuerdo con distintas academias responsables de definir y actualizar la mayoría de idiomas del mundo, como la National Commission on Language and Script Work (国家语言文字工作委员会) de China, la Real Academia Española (RAE), Academy of the Arabic Language (مجمع اللغة العربية), la Royal Galician Academy, o Council for German Orthography (Rat für deutsche Rechtschreibung) por citar sólo algunas. De estas instituciones obtendrá los diccionarios actualizados que serán utilizados por las herramientas del gigante de Redmond para comprobar que estamos escribiendo como debemos. En el caso del inglés es distinto porque no existe un organismo regulador, pero se atenderán a las guías oficiales publicadas por los países donde es la lengua oficial.
En Visual Studio tendremos disponibles propiedades a nivel de proyecto y de cada archivo (de código, recursos, diseñadores, etc.) en el que indicaremos el idioma en el que debe realizarse la comprobación.
Por supuesto, también ha sido actualizado intellisense para alternativas a las palabras que vayamos escribiendo e incluso un menú de sinónimos, de la misma forma que Microsoft Word:
Para los casos en que el idioma pueda cambiar dentro del propio archivo o incluso en distintas secciones de éste, se han añadido directivas
#pragma que pueden usarse en cualquier punto. Por ejemplo, en el siguiente código se han detectado dos errores de compilación para la porción escrita en español, en un comentario y en el nombre de un método:
Por supuesto, las comprobaciones atienden al camel casing, es decir el nombre del método
ObtenerFactura() se entenderá correcto, mientras que Obtenerfactura() no lo será. Otra ventaja colateral de esta característica es que dejaremos de utilizar nombres de variable sin sentido como “s”, “xyz”, tendiendo a que realmente se refleje su intencionalidad como “saldo” o “coordenadasTridimensionales”. Se está estimando, sin embargo, excluir las variables de tipo índice obvias como la típica “i” en un bucle for por razones históricas.Las mismas directivas y propiedades se aplicarán en las comprobaciones de cadenas de texto, recursos (.resx) y diseñadores de la aplicación. De esta forma, podremos estar seguros de que los textos que lanzamos a los usuarios habrán superado un nivel mínimo de calidad, que falta hace en muchas aplicaciones:
En fin, creo que es una iniciativa absolutamente necesaria para mejorar la calidad interna de nuestro código y, como extensión, de nuestras aplicaciones, y me gustaría felicitar a Microsoft por haber tomado esta controvertida decisión. Seguro que traerá mucha polémica, pero estoy convencido de que es por el bien de la humanidad.
Aunque en principio esta nueva característica sólo estará disponible para Visual Studio 2015, no se descarta la creación de extensiones para todas las versiones de Visual Studio, comenzando en la 2005. Está previsto incluso su introducción en el proyecto Omnisharp para poder aplicarlo en entornos de desarrollo más allá de Visual Studio, lo que abriría su uso a otras plataformas como Mac o Linux, y de la posibilidad de desarrollar plugins oficiales para Git, Mercurial, Subversion, TFS y sistemas de integración continua que permitan automatizar estas comprobaciones.Se avecina un año maravilloso donde los sistemas de control de código fuente podrán rechazar un commit o check-in por tener faltas de ortografía, o en el que en nuestra mesa, junto a clásicos como C Programming language o Code Complete , podremos encontrar el diccionario de la real academia de la lengua española.
¡Feliz escritura de código!
[Actualizado 30/12]
Nota para despistadillos: obviamente no es real, se trata simplemente de una broma del Día de los Inocentes. Así que tranquilos, podemos seguir dando patadas al diccionario impunemente en nuestro código :-DDD
Nota para despistadillos: obviamente no es real, se trata simplemente de una broma del Día de los Inocentes. Así que tranquilos, podemos seguir dando patadas al diccionario impunemente en nuestro código :-DDD
Publicado en Variable not found.
martes, 16 de diciembre de 2014
Como ya hemos visto por aquí en alguna ocasión, hace tiempo que MVC soporta controladores asíncronos, permitiendo la implementación de acciones muy eficientes desde el punto de vista de la utilización de los recursos del servidor.Sin embargo, en cuanto pretendíamos llevar a los action filters la misma filosofía nos encontrábamos con que la infraestructura no estaba preparada, es decir, no teníamos una forma clara de introducir llamadas asíncronas en el cuerpo de los filtros. Como consecuencia, todas las tareas que se realizaban en su interior eran puramente síncronas y dejaban bloqueados los hilos destinados a procesar peticiones mientras se completaban las operaciones, lo cual es especialmente un despilfarro cuando se trata de tareas de entrada/salida.
Afortunadamente esto parece que va a terminar con ASP.NET Core MVC, que soportará ya esta solicitada característica. Pero ojo, que Core MVC está aún en desarrollo, por lo que todo lo que cuento a continuación puede cambiar.
Pero empecemos desde el principio, viendo qué ha cambiado por abajo para que sea posible crear filtros con código asíncrono en su interior. Quizás sea una lectura un poco densa, pero creo que es interesante para comprender cómo funcionan las cosas por dentro.
miércoles, 3 de diciembre de 2014
Aunque aún en beta e inmersa en un intenso proceso de desarrollo, la próxima versión de ASP.NET MVC está tomando forma en los hornos de Microsoft, y, sin ser definitivas, ya se pueden ver cuáles serán las novedades principales que la acompañarán. En futuros posts iremos entrando en mayor detalle, pero de momento vamos a echar un vistazo desde una cierta distancia para tener la idea general sobre dónde estamos y la evolución que vamos a encontrar en las nuevas versiones de tecnologías y plataformas, de forma que podamos ver en qué nos afectará como desarrolladores y, en definitiva, para qué tenemos que irnos preparando.
Disclaimer: estamos aún en una fase en la que algunas cosas pueden cambiar y aún no existe información exhaustiva de muchos detalles, por lo que pueden existir ausencias o imprecisiones. Pero bueno, digo yo que el grueso será más o menos correcto ;-)
martes, 25 de noviembre de 2014
Seguimos con esta serie sobre las novedades de C# 6, y esta vez le toca el turno a una solicitada característica que recientemente ha entrado a formar parte de las elegidas para formar parte de esta nueva versión de nuestro lenguaje favorito: la interpolación de cadenas.Dado que aún se encuentra en desarrollo no es posible probarlo de forma sencilla, por lo que de momento tendremos que conformarnos con sacar conclusiones basándonos en la discusión de diseño en Codeplex y de la documentación existente. Avisan además que la especificación puede ser modificada, por lo que todo lo que digamos aquí aún puede variar algo, aunque mayormente será (espero) válido.
martes, 18 de noviembre de 2014
Seguimos hablando de las novedades de C# 6, y en esta ocasión nos centraremos en una interesante característica cuyo nombre, sinceramente, no estoy seguro de ser capaz de traducir de forma correcta del original “Expression bodied function members”. Quizás sería algo así como “expresiones en cuerpo de miembros de función”, pero bueno, lo importante no es el nombre sino el concepto, así que vamos a centrarnos en él.
martes, 28 de octubre de 2014
Seguimos con la serie donde vamos desgranando las novedades de C# 6, y en esta ocasión vamos a ver algunas mejoras en el uso de bloques try/catch, a las que seguro podremos sacar buen partido.En este post trataremos dos temas distintos. En primer lugar, comentaremos la introducción del soporte de
await en bloques catch/finally, y seguiremos con la nueva capacidad de filtrado de excepciones.Vamos a ello :-)
martes, 21 de octubre de 2014
En otras ocasiones hemos hablado de novedades que acompañarán a la próxima revisión de C# que nos ahorraban algo de tiempo y pulsaciones de tecla a la hora de codificar algunos escenarios bastante frecuentes, a la vez que mejoraban la legibilidad. Pues en esa misma línea, vemos ahora una nueva forma de inicializar colecciones clave-valor, como son los diccionarios. Ciertamente es un cambio bastante pequeño, de los que fácilmente podrían pasar desapercibidos junto a otras novedades de mayor peso, pero creo que también vale la pena conocerlo.
jueves, 16 de octubre de 2014
Hace unos días mostrábamos por aquí el nuevo operador nameof que acompañará a C# 6, y cuya función, resumidamente, es obtener el nombre a nivel de código de la variable o miembro a la que se aplica:
En los comentarios de este post, el amigo Kiquenet se preguntaba qué incidencia podía tener el uso de este operador en el rendimiento de nuestras aplicaciones, y esa duda es la que vamos a responder muy rápidamente ahora.
martes, 7 de octubre de 2014
Cuando los lenguajes evolucionan, no todas las novedades son espectaculares ni revolucionan la forma de escribir nuestro código. A veces la cosa va simplemente de añadir pequeños detalles que nos hacen la vida más fácil y ayudan a evitar errores.Y hoy hablaremos de uno de ellos: el nuevo operador
nameof, que acompañará a C# a partir de su versión 6.
