Descifrando el lío de ASP.NET vNext: versiones, disponibilidad, Visual Studio...
Men? de navegaci?nMen?
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

Descifrando el lío de ASP.NET vNext: versiones, disponibilidad, Visual Studio...

ASPNET-vNextActualización Enero 2016: En Enero de 2016 Microsoft actualizó el versionamiento de la plataforma a una cosa mucho más razonable que la situación que se intentaba aclarar aquí. No obstante todo esto sigue siendo relevante y el artículo sigue siendo válido (excepto los nombres de las versiones) para entender la situación, así que te recomendamos leerlo. El nuevo aclarando la nueva terminología lo tienes aquí.

Aunque en general siempre me han gustado las tecnologías de Microsoft, lo que menos me gusta de ellos -con diferencia- es lo sumamente malos que son en comunicación, al menos en lo que respecta a los programadores. Y es que, parafraseando el mítico libro del también mítico Alan Cooper, los locos están gobernando el manicomio: permiten a los equipos de desarrollo que decidan ciertas cosas, y luego pasa lo que pasa... Y lo peor quizá sea la manera que han tenido siempre de versionar la plataforma .NET, como ya he dicho en otras ocasiones.

En este caso me voy a centrar en la famosa nueva versión (¿o será más de una?, ahora lo veremos) de ASP.NET y de la propia plataforma .NET, lo que se ha dado en llamar ASP.NET vNext.

NOTA:  Este es un artículo largo, pero creo que merece la pena leerlo con detenimiento para entender bien los cambios que están por venir, así como el galimatías en el que se ha convertido seguirle la pista a la plataforma .NET. Al final he incluido un gráfico y también un pequeño texto de resumen para impacientes, pero te recomiendo no obstante que trates de leerlo entero.

En primer lugar, el equipo de desarrollo de ASP.NET ha utilizado internamente desde hace muchos años el nombre clave "vNext" para referirse a las novedades que estaban preparando para la próxima versión de la plataforma. Este era un nombre muy apropiado porque, si tenías la suerte de estar en su grupo de "Insiders" (yo llevo mucho años en él), las podías probar con bastante antelación aunque rompieran, y sabías qué cosas nuevas iban a incorporarse a la plataforma en el futuro. Las nuevas versiones de ASP.NET solían coincidir con versiones nuevas de Visual Studio o de sus Service Pack o Updates, con una cadencia de aparición de entre uno y dos años. Perfecto para poder asentar lo anterior y tener una cierta predictibilidad, pero malo para ir incorporando rápidamente cosas nuevas que demandara el mercado.

Esa cadencia para liberar versiones que tan cómoda resultaba, no casaba bien con lo que hacía la competencia, que en su mayor parte son productos Open Source. Así que hace un tiempo el equipo de herramientas de desarrollo de Microsoft se embarcó en una cruzada gigantesca para convertir en Open Source la mayor parte de la plataforma (lo cual es estupendo), pero con todas sus consecuencias... Entre ellas lanzar nuevas versiones mucho más rápido y además desconectadas de Visual Studio (lo que ellos llaman Out of Band). El primer producto importante que se hizo Open Source y empezó con esta dinámica fue ASP.NET MVC en 2009, aunque se trataba de una licencia MS-PL (un open source "descafeinado") y no admitía colaboraciones externas. En marzo de 2012 ya se publicó con licencia Apache. El anuncio de que Entity Framework se hacía Open source fue algo más tarde, en julio de 2012, aunque lo hicieron desde un principio de forma mejor y más abierta.

Poco a poco han ido incorporando todo lo demás, y han empezado a "darlo todo" a partir de su anuncio de noviembre de 2014.

Todo esto está muy bien, pero el problema es que están causando una confusión enorme entre los programadores, debido sobre todo a la forma de versionar. Hasta muchos de los "insiders" tienen un "cacao" terrible y se llevan a confusión con esto.

Se anunció públicamente que se estaba trabajando en la nueva versión "revolucionaria" de .NET y de ASP.NET hace ya bastante más de un año. Se ve que no conocían el famoso efecto Osborne (nada que ver con Bertín), porque ese anuncio lo que provocó es que mucha gente dejara la adopción de la tecnología hasta que la nueva versión estuviera disponible. Pero es que para que esto ocurriese faltaban ¡casi dos años! desde que lo anunciaron, como veremos enseguida. Así que mucha gente que tenía pensado aprender MVC para su próximo proyecto, lo dejó para más adelante y acabó aprendiendo Node.js u otra tecnología. Y todo por un anuncio a destiempo y mal comunicado :-(

Vamos a darle un repaso a todo esto para ver si aclaramos el lío.

1.- Versiones de la plataforma .NET

En primer lugar comenzaremos por la base: el framework. Hasta ahora teníamos una única plataforma, el .NET Framework, que disponía de varias versiones que se fueron liberando desde la 1.0 en febrero de 2002 hasta la última, .NET 4.5, con Visual Studio 2013, en octubre de 2013.

Bien es cierto que existían algunas variantes reducidas de la plataforma, como el .NET Framework Client Profile, la .NET Compact Framework para aplicaciones móviles, o el subconjunto de .NET que se usaba en Silverlight y que realmente fue la primera versión de .NET oficial que era multiplataforma. No obstante todas estas variantes no eran sino subconjuntos más o menos "adaptados" de la misma plataforma monolítica.

Para terminar de complicar las cosas,  por debajo de la plataforma .NET está el CLR (Common Language Runtime) que es el componente de la plataforma encargado de ejecutar los programas .NET y que provee servicios como la seguridad de tipos, la gestión de la memoria, gestión de hilos, gestión de excepciones, etc... Este componente de .NET lleva su propio versionamiento independiente, y de hecho actualmente va por la versión 4. Podemos resumir la relación de las versiones de .NET con las versiones del CLR de la siguiente manera:

  • CLR 1.0 --- .NET 1.0
  • CLR 1.1 --- .NET 1.1
  • CLR 2.0 --- .NET 2.0, 3.0 y 3.5  (sí, si ejecutas .NET 3.5 por debajo el CLR es el 2.0)
  • CLR 4 --- .NET 4 y 4.5 (sí, le quitaron la revisión y ya no es "punto cero" ni "punto nada").

En este enlace puedes encontrar muchos más detalles.

Con ASP.NET vNext se hizo saber que iba a haber una nueva variante de la plataforma: .NET Core que será una versión reducida de ésta, muy ligera, rápida y capaz de ejecutarse en todas las plataformas (Windows, Mac y Linux). Hace unos días os contábamos aquí mismo las diferencias que existían entre la versión completa del Framework y .NET Core.

Bien, resulta que la nueva versión completa de .NET será .NET Full Framework 4.6 o Full CLR 4.6. Y la versión inicial de .NET Core se llamará .NET Core 5. Pero paradójicamente como Core va a ser un subconjunto de la Full CLR, en realidad la "versión" 5 es más pequeña que la 4.6 :-O

.Net 5 < .Net 4.6  -- WTF?

¿Es o no es demencial? Lo peor es que cuando nos preguntaron a los "insiders" nuestra opinión hace ya muchos meses, creo que hubo un consenso bastante amplio en que esto era un error enorme. Pero no nos hicieron caso.

Por cierto, si lees por ahí sobre la versión 4.5.3 de .NET, están hablando de .NET 4.6. Cuando anunciaron la versión Core inicialmente pensaban dejar la versión de .NET "tradicional" como 4.5.3, pero poco después decidieron que los cambios eran lo suficientemente importantes como para subirle un poco más la versión, y quedó 4.6.

2.- ASP.NET

La plataforma de Microsoft para crear aplicaciones Web está formada a su vez por multitud de tecnologías, todas con el nombre ASP.NET delante y muchos apellidos:

  • Web Forms
  • MVC
  • Web API
  • SignalR
  • WebPages

En la próxima versión vamos a tener realmente dos versiones diferentes de ASP.NET:

  • ASP.NET 4.6: alineada con la versión del CLR, esta versión seguirá la línea tradicional de lo que ha habido hasta ahora. Es decir, si sabes ASP.NET MVC 5, Web API o ASP.NET Web Forms podrás seguir usando esta versión como siempre. Cuando se libere incluirá algunas mejoras para todas las tecnologías de la lista anterior, pero puedes tener la tranquilidad de que no va a romper nada.
  • ASP.NET 5: esto es realmente lo que se ha llamado ASP.NET vNext y es de lo que se habla cuando se usa esta denominación tan funesta (¿cómo le llamarán a la siguiente versión? ¿vNext+?). Para simplificar diremos que incluye todas las tecnologías anteriores excepto Web Forms, que se quedan tan solo para la versión completa del framework (la 4.6) y por lo tanto no serán multiplataforma.

Así a primera vista parece que usar ASP.NET 5 es estupendo pues funcionará tanto en .NET 4.6 como en Core 5 ¿no? El problema es que se trata de una tecnología completamente nueva, escrita desde cero para que sea ligera, multiplataforma, etc... O sea, en consonancia con .NET Core. Y las versiones que se utilizan serán completamente diferentes e incompatibles con lo actual (y con las de ASP.NET 4.6).

Atención a los números de versión: si usas ASP.NET 4.6 estrás trabajando realmente con ASP.NET MVC 5.x (actualmente en su versión 5.2.3), pero si usas ASP.NET 5 en realidad estarás programando para ASP.NET MVC 6!!

Una confusión enorme. Es más, por ejemplo, con ASP.NET 5 estarás usando SignalR 3.0, la próxima versión que saldrá con .NET 5, pero con ASP.NET 4.6 estarás usando SignalR 2.

Curso de ASP.NET Core MVC: Tu mejor opción para aprender online y en español.

3.- Entity Framework

Aunque de esto no se está hablando tanto, también tiene un buen lío montado.

Resulta que el ORM de Microsoft lleva ya casi una década en desarrollo (actualmente está en su versión 6) y en este tiempo se ha convertido en un bicho bastante grande y en cierto modo pesado. Eso no casaba bien con la nueva filosofía de ligereza de .NET Core, así que la nueva versión que aparecerá será Entity Framework 7.

Esta versión es una versión completamente nueva, escrita casi desde cero y completamente separada de la actual versión 6. Por ello, cuando salga tendrá en realidad menos características que la actual EF 6, pero a cambio será ligera, rápida, multiplataforma y podrá además acceder a bases de datos NoSQL o a otras como SqlLite o PostgreSQL.

EF7 funcionará en .NET 4.6 y en .NET 5. Pero EF6 que evolucionará por su cuenta, no funcionará en .NET 5.

¿Quiere decir esto que EF7 va a sustituir a EF6?. En absoluto. Son dos versiones diferentes y (casi) dos productos diferentes que se mantendrán en paralelo. De hecho el propio equipo de Entity Framework comentó en su blog públicamente lo siguiente:

image

Es decir, que cuando salga "vNext" y con ello EF7, no quiere decir que Entity Framework 7 sea la versión recomendada. Quiere decir que será la versión que deberás utilizar con .NET Core 5, pero todavía estará incompleta y le faltarán muchas funcionalidades. De hecho en .NET Full será recomendable utilizar EF6 si puedes, y ambas versiones irán paralelas.

4.- Resumen de versiones

Para resumir brevemente todo lo que hemos visto, he hecho este gráfico que creo que ilustra más o menos claramente el lío de versiones que tenemos, tanto de .NET como de ASP.NET, MVC y Entity Framework:

Plataforma-NET-vNext-2015
Pulsa para aumentar

No conviene olvidar que aunque los números de versión son mayores tanto para Core Framework, como para ASP.NET 5 y Entity Framework 7, en realidad son subconjuntos de las tecnologías correspondientes en Full Framework 4.6, que tienen números de versión menores.

Nota: Aquí conviene aclarar además otra cuestión importante: En realidad aunque en el gráfico anterior se han puesto por separado, en ASP.NET 5, Web API ya no es una tecnología separada de MVC y en realidad forma parte de ésta. Es decir, no hay como tal un "ASP.NET Web API 6" como se ve en el gráfico, sino que ASP.NET MVC incluye a Web API también y está todo mejor integrado. Lo he puesto por separado igualmente en el diagrama para que nadie se lleve a engaño y pueda pensar que Web API desaparece.

5.- Disponibilidad

Bien, ahora que más o menos está aclarado el lío de las versiones, los números de versión y qué incluye cada uno, vamos a ver cuándo estará todo esto disponible:

  • .NET Full Framework 4.6: estará disponible junto con la versión definitiva de Visual Studio 2015, el día 20 de Julio de 2015. Ojo, saldrá unos días antes que la versión definitiva de Windows 10 (que sale el día 29 de Julio). En esos días no podrás instalarla en versiones preliminares de Windows 10, así que solo en Windows 8.1.
  • Core Framework 5 + ASP.NET 5: (estas fechas las han indicado los propios miembros del equipo en un hangout hace unos días):
    • Beta 6: A finales de Julio, poco después de Visual Studio 2015
    • Beta 7: A finales de Agosto.
    • Beta 8: A finales de Septiembre.
    • Release Candidate: hacia finales del otoño de 2015 (o sea hacia Diciembre de 2015), pero es difícil estimarlo con tanto tiempo de antelación. Esta versión no será todavía definitiva pero se parecerá bastante y de hecho vendrá con una licencia "Go Live" para poder poner en producción aplicaciones con soporte por parte de Microsoft (si es que eres tan valiente como para hacerlo).
    • Versión definitiva: No se sabe. Supongo yo (pero es una cábala) que para el primer trimestre de 2016.
  • Entity Framework 7: no hay fechas definitivas, pero de momento está en un estado muy prematuro y sí que han manifestado que saldrá seguramente junto a Core 5, es decir, supongo que durante el primer trimestre de 2016 también, aunque con características recortadas todavía.

Puedes suscribirte a los anuncios de versiones de ASP.NET y sus novedades en GitHub para seguir los cambios.

En resumen

Como vemos el lanzamiento de ASP.NET "vNext" y todo lo relacionado con ello se ha hecho de manera (en mi opinión)demasiado anticipada que hizo que muchos programadores entraran en pánico y decidieran esperar para aprender o para crear nuevas aplicaciones con ASP.NET. Sin embargo todavía es muy pronto.

Los de Microsoft han creado un lío de versiones bastante importante que he intentado desentrañar en este post. Tenemos versiones diferentes de la plataforma, versiones diferentes de ASP.NET, versiones diferentes de las sub-tecnologías dentro de .NET y versiones diferentes de Entity Framework. Los números más grandes no quieren decir que tengan más características, sino que en realidad son versiones reducidas de los números de versión más pequeños, entre otras cosas porque se han escrito de nuevo desde cero, son más ligeros y son multiplataforma.

En mi opinión deberían haberle dado un nombre diferente a las dos ramas de la tecnología, diferenciándolas más claramente, y no un número de versión distinto. Habría simplificado todo mucho su comprensión.

Las fechas de lanzamiento de unas versiones y otras varían también bastante, estando disponible la Full Framework 4.6 (la que se puede considerar más tradicional) en unos pocos días, y el resto se esperan todavía definitivas para principios del año que viene.

¡Espero que te haya ayudado a aclarar todo este lio!

Nota: Mis agradecimientos a José María Aguilar y Unai Zorrilla por revisar este artículo antes de su publicación.

José Manuel Alarcón Director de campusMVP, es ingeniero industrial y especialista en consultoría de empresa. Ha escrito diversos libros, habiendo publicado hasta la fecha cientos de artículos sobre informática e ingeniería en publicaciones especializadas. Puedes seguirlo en Twitter en @jm_alarcon o leer sus blog técnico o personal. Ver todos los posts de José Manuel Alarcón

No te pierdas ningún post

Únete gratis a nuestro canal en Telegram y te avisaremos en el momento en el que publiquemos uno nuevo.


Comentarios (15) -

Directo a favoritos, vengo siguiendo "la novela" de asp.net vNext y me pensé que lo  tenía bastante claro hasta que leí este post.

Sinceramente la política de comunicación y versionado de tecnologías de Microsoft es un desastre. Aquellos sistemas que se desarrollen con esta versión se van a convertir en un lastre para el mantenimiento ... hoy sabes que si tienes un desarrollo en el .net framework 2 si tienes instalado el 4 vas a poder correrlo sin problemas .... ahora puedes tener algo hecho con el 4.6  y si instalas el 5 no funciona ...

Cuál es el objetivo de MS a futuro con esto? De a poco focalizarse en Core y de a poco ir dejando de lado el full framework? O va a mantener las dos ramas de productos? Lo último me parecería raro, duplicaría esfuerzos...

Responder

José Manuel Alarcón
Spain José Manuel Alarcón

Hola Pablo:

Yo creo que mantendrán las dos, aunque la "tradicional" seguramente irá con pocos añadidos porque se tienen que centrar en la nueva para darle más funcionalidad. Pero no lo sé con certeza, es sólo una idea.

En mi opinión deberían haberle dado un nombre diferente a esta línea y empezar a versionarlo desde 1.0. Por ejemplo: .NET Core 1.0 y ASP.NET Core 1.0 o algo por el estilo. De este modo se dejaría muy clara la distinción entre ellos y al mismo tiempo seguiría estando claro que se trata de la misma base (.NET con C#, etc...).

Pero en Redmond hay gente que cobra mucho más que yo (y seguro que son más listos que yo) que lo ha decidido de otro modo así que...

Saludos!

Responder

Muchas gracias por el artículo, ha sido muy aclaratorio.

En nuestra empresa llevamos muchos años usando WCF, ¿en qué lugar queda esta tecnología en este nuevo ecosistema?, ¿está soportado en .NET Core?.

Gracias.

Responder

José Manuel Alarcón
Spain José Manuel Alarcón

Hola francisco:

Sí, de hecho han empezado hace poco (a finales de mayo) a hacer Open Source WCF y quieren que esta nueva versión funcione bajo .NET COre:

www.dotnetfoundation.org/blog/wcf-is-open-source

Lo que ocurre es que no tengo ni idea de en que punto está esto ni qué idea tienen de cuándo va a estar listo. Yo realmente no soy un gran fan de WCF y no lo sigo tan de cerca como otras cosas. Probablemente le pase como a lo demás: que esté para cuando salga .NET Core pero que esté muy "pelado", con poca funcionalidad.

Me alegro de que te haya gustado el artículo. Creo que era necesario aclararlo y deshacer un poco el lío que han montado.

Saludos!

Responder

Hola de nuevo,

Después de haber hecho algunas investigaciones y haber contactado con Ron Cain, coordinador del proyecto de WCF en GitHub, me han confirmado que la implementación de WCF sobre .NET Core, NO es la implementación de la parte servidora, sino de la parte cliente de WCF.

Esto implica que no será posible ejecutar servicios WCF sobre Linux ni Mac, solo, como hasta ahora, sobre Windows. Lo que están haciendo es que aplicaciones Windows Universal Apps, Mobile Apps y servidores intermedios corriendo Web API, puedan invocar a servicios WCF que corren en Windows.

Si somos suficientes los clientes interesados en disponer de la posibilidad de WCF Services corriendo sobre .NET Core se comprometen a estudiar la petición. Nos invitan a que solicitamos esta característica en el proyecto de GitHub (https://github.com/dotnet/wcf/) y así ellos poder valorar el coste de implementación.

Así que, por favor, a todo aquel que esté interesado en esta característica que se pase por la web del proyecto y la solicite. WCF es una muy buena tecnología y es una lástima que no tengan pensado implementarla sobre .NET Core.

Personalmente estoy un poco cansado de ver cómo cada dos por tres se cambia tecnología que funciona y que es potente (dígase WCF, Silverlight, WPF, etc.) por otras que hacen menos, simplemente por modas o por marketing, vendiéndonos las bondades de lo nuevo, cuando realmente lo que están haciendo es reinventar la rueda. Mejor sería se dedicarán los recursos a hacer que las ruedas existentes funcionen mejor y a perfeccionarlas, sin hablar del impacto que esto tiene en las empresas de desarrollo de software, donde tenemos que dedicar el tiempo a aprender cosas nuevas, en vez de dar valor funcional a las aplicaciones que hacemos, que es realmente lo que nuestros clientes valoran.

Saludos

Responder

José Manuel Alarcón
Spain José Manuel Alarcón

Hola Francisco:

Muchas gracias por la información. Es muy interesante.

Respecto a tus apreciaciones sobre el modo de actuar en estos asuntos: estoy totalmente de acuerdo contigo. Hay que avanzar técnicamente e innovar, pero no a costa de dejar de lado lo existente. Existen programadores que quieren estar siempre a la última y en muchas ocasiones se mueven por modas o tendencias, pero una gran mayoría lo que prefieren es estabilidad y que su inversión en aprender y dominar una tecnología les de tiempo a recuperarla.

Saludos!

Responder

Alberto Población
Spain Alberto Población

Gracias por "desenredar la madeja" de las versiones con este artículo. Sabía que teníamos un lío tremendo de versiones, pero no me había dado cuenta de hasta dónde llegaba hasta leerlo aquí.

Responder

Excelente explicación,

Se que el crear un libro de estos temas es un trabajo bien arduo, pero pienso que seria muy bien valorado por la comunidad hispano parlante en estos momentos un libro enfocado al desarrollo de aplicaciones empresariales, creadas con ASP.net MVC V-next utilizando las tecnologías mencionadas en este articulo. En estos temas pueden existir mucha información en internet pero  libros en español muy pocos.  

Responder

Excelente artículo! Muchas gracias por aclararnos todo este lío.

Responder

Hola José. leyendo y consultando también otros sitios, creo que es mejor no emocionarnos tanto con el nuevo .net 5... y 4.6 tenerlo en reserva.. pero creo que con lo que seguimos trabajando con vs 2013 mvc 5 y entityframeW 6 con eso basta! (por el momento para app web)

pero aun nos dejan esperando para que haya un .net framework para linux y ios (real) por que con tanta espera seguiré pensando en Java, como lenguaje multiplataforma.

En cada versión MS agrega y quita cosas del .net frameWork a otros Frameworks como WorkFlow foundation, Sync framework y como mencionaron un comentario aca, el WCF que pasará con estos FM´s??

Responder

José Manuel Alarcón
Spain José Manuel Alarcón

Hola Germán:

Es que yo pienso que la gente se emocionó en primera instancia con "vNext" porque pensaba que era lo mismo pero muy mejorado y multiplataforma. La realidad lo que nos muestra es que es una plataforma diferente aunque similar, con grandes mejoras en algunos aspectos (como ligereza, que es multiplataforma, Open Source...) pero más limitado en otras, y además incompatible.

Nuevamente insisto en que creo que la forma de comunicarlo y nombrarlo ha sido el mayor problema. Si le hubieran llamado de otro modo diferente (.NET Core 1.0, por ejemplo) y desde el primer momento hubieran comentado que es otra cosa y que se van a mantener las dos, la gente se lo hubiera tomado de otra manera. Lo actual ha hecho que, como tú, muchas personas se hayan ido a otras plataformas como Java, Node, etc... Una pena, porque la tecnología está muy bien. Les ha pasado lo mismo a los de Google con AngularJS, (/recursos/post/191;Debo-aprender-AngularJS-ahora-o-esperar-a-AngularJS-20.aspx) con la diferencia de que ellos no se juegan tanto como Microsoft con estas cosas...

Respecto a los sub-frameworks de .NET: hasta la fecha siempre los han hecho compatibles hacia atrás, así que por eso no me preocuparía si sigues usando .NET 4.6 "clásico". Solo debes preocuparte si usas .NET 5.0 porque ahí sí que hay diferencias importantes en muchas cosas porque se han escrito desde cero prácticamente.

Saludos.

Responder

Hola José.

    Tengo este artículo en favoritos desde que lo publicaste, y hoy vuelvo a leerlo para aclarar el panorama. No tengo más que agradecer tu esfuerzo para desenredar esta madeja que hicieron los muchachos de MS.

    Aunque desde el momento de la publicación haya pasado un tiempo, aún estas tecnologías no están maduras, y por ese motivo quisiera consultarte un par de cuestiones.

     ¿Recomendarías que alguien que tenga que iniciarse desde cero con MVC empiece usando MVC 6? ¿Y EF 7? ¿Convendría .NET Core o sería mejor seguir por la línea tradicional, con .NET 4.6?


Gracias por todo, un saludo desde Argentina

Responder

José Manuel Alarcón
Spain José Manuel Alarcón

Hola Franco:

Gracias por comentar. Me alegro de que el artículo te haya resultado útil.

Las preguntas que me haces son peliagudas porque dependen mucho de tu situación personal y de tus objetivos, pero te daré mi opinión.

Mi opinión es que deberías conocer antes las tecnologías actuales. Por diversos motivos, entre los que destaco:

   - La tecnología actual te abre más posibilidades por el momento.
   - Cuando salga lo nuevo aún estará "verde" y seguramente tardará un tiempo en ser lo que tiene que ser. Desconozco si de entrada ya será posible de verdad poner en producción todo lo que saquen (aunque ellos digan que sí).
   - Salvo que solo vayas a trabajar en un proyecto propio y uses lo nuevo, lo normal es que tengas que trabajar y mantener aplicaciones creadas con la versión actual, por lo que conviene conocerla en cualquier caso.
   - Desconocemos el futuro que tendrá esa nueva tecnología. Microsoft (y en realidad todas estas empresas) no se caracterizan precisamente por ser fieles a lo que predican. Hay muchas tecnologías que en su día se vendían como "el futuro" y que se quedaron el camino. Dos ejemplos: Documentos ActiveX en los '90 y Silverlight más recientemente. No creo que pase con vNext, pero mejor tener un plan de backup.

En resumen: yo aprendería lo actual bien y luego te resultará más sencillo aprender lo otro y tendrás más oportunidades. Igual peco de conservador, pero...

Saludos!

Responder

Alberto T.
Spain Alberto T.

Excelente artículo.
Mil gracias por quitarle el velo de misterio (confusión) a este tecnológico thriller!

Responder

Muy buen artículo y aclaro algunas dudas.

Responder

Agregar comentario