Migrando aplicaciones de .NET al nuevo .NET Core - Preguntas y respuestas
Men? de navegaci?nMen?
Categorías

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

Migrando aplicaciones de .NET al nuevo .NET Core - Preguntas y respuestas

NetCore-Xamarin-Migracion

.NET Core es la nueva generación de tecnologías basadas en .NET y orientadas a la nube. No se trata de una nueva versión llamada a sustituir a la anterior, sino que es una nueva tecnología que se mantendrá en paralelo a la tecnología actual. Tiene unos objetivos diferentes: sobre todo que sea multi-plataforma (Windows, Linux y Mac), que ofrezca más rendimiento y menos consumo de recursos para su uso en la nube, y que sea totalmente modular. Hace un tiempo te explicamos en un artículo en qué consiste .NET Core, qué contendrá y qué esperar de esta tecnología en el corto plazo.

Hace poco el equipo de .NET Core sacó un artículo en el que explicaban a vista de pájaro qué opciones existen para poder migrar tus aplicaciones desde la versión completa de .NET a la más liviana y multi-plataforma nueva versión, que por otro lado no ha sido lanzada todavía, pero está cerca. Queremos ofrecerte un resumen aquí.

¿Qué aplicaciones se pueden portar?

En primer lugar hay que tener claro que .NET Core no permite crear cualquier tipo de desarrollo. Por el momento se centra en tres tipos fundamentales de aplicaciones:

  • Aplicaciones y servicios Web: ésta es de lejos la aplicación principal y la más popular.
  • Aplicaciones universales para la plataforma Windows: aquí pierde un poco de sentido lo de que sea multi-plataforma, aunque nos imaginamos que, tras la reciente compra de Xamarin, la intención es ampliarlo para que cubra desarrollos multi-plataforma también. En ese caso sí que será algo muy a tener en cuenta.
  • Aplicaciones de consola: ideales para crear herramientas de administración del sistema que se ejecuten en Windows, Mac y Linux.

Veamos qué ventajas sacaríamos de portar aplicaciones de cada tipo a .NET Core.

¿Por qué deberíamos (o no) portarlas?

En el caso de las aplicaciones web las principales ventajas de migrarlas serían que se podrían ejecutar en Mac o Linux además de Windows, que podrías usar de manera más eficiente los recursos del servidor al desplegar exactamente la funcionalidad del framework que vayas a usar, y que se ejecutarán más ágiles en general por estar .NET Core pensado para un entorno Cloud, donde la eficiencia prima. Si es un servicio Web API la migración es sencilla. No tanto con ASP.NET MVC (aunque es relativamente sencillo). Imposible si usas Web Forms.

En el caso de aplicaciones pensadas para Windows 8/10, si ya usas la plataforma universal no tienes nada que migrar: funcionarán sin problemas en .NET Core. En el caso de que sean aplicaciones basadas en Silverlight la migración es muy simple pues solo hay que cambiar algunos espacios de nombres y poco más (hasta hay una herramienta para pseudo-automatizar esto). Si son aplicaciones de escritorio basadas en WPF (y ya no digamos en Windows Forms), entonces la migración es complicada porque no está soportado en Core. Ahora bien, WPF se parece mucho al lenguaje de la interfaz de WinRT, por lo que en este caso el aprendizaje al menos será mucho menor.

Finalmente si tienes una aplicación de consola, el atractivo principal de la migración sería el poder usarlas en los tres principales sistemas operativos del mercado. Si tu aplicación hace cosas poco ligadas al funcionamiento de bajo nivel del sistema operativo (por ejemplo, si procesa archivos y cosas similares), entonces la migración será más o menos sencilla en función de las bibliotecas de las que dependa. En caso de que uses cosas como automatización COM o APIs del sistema, vete olvidándote de ello.

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

¿Qué APIs y funcionalidades de .NET no están soportadas en .NET Core y nunca lo estarán?

Existen una serie de tecnologías que no están soportadas en .NET Core y nunca lo van a estar ya que Microsoft ha decidido considerarlas "problemáticas" (sic). Otras no lo están todavía pero puede que lo estén en el futuro, aunque en muchos casos ni siquiera han pensado en cómo harían esa migración, y solamente se considerarán llegado el caso.

Veamos las más importantes:

Reflection

.NET está íntimamente ligado al concepto de "Reflexión", es decir, el poder examinar en tiempo de ejecución las diferentes clases y objetos, al contrario que otros lenguajes más estrictos que requieren compiladores y runtimes que usen solo información estática. Tan ligado está .NET a este concepto que la clase Object, base de todas las demás clases del framework, depende directamente de Reflection  y dispone de un método llamado GetType que devuelve un objeto con toda la información sobre el tipo del objeto actual, para poder enumerar sus propiedades, métodos y muchos otros detalles.

En .NET Core esto ha cambiado puesto que para poder hacer totalmente modular la plataforma es necesario tener información estática sobre la funcionalidad a utilizar, pudiendo desplegar así solo lo que sea necesario en cada momento. Así que el equipo decidió romper la compatibilidad y que System.Type ya no represente toda la información de un tipo, sino solamente su nombre :-S

Si necesitas acceder a las capacidades de reflexión tendrás que utilizar un nuevo método extensor específico de System.Type llamado GetTypeInfo() e incluir el módulo System.Reflection.

Aquí tienes un artículo sobre todos estos cambios. A mayores, y dado que se han desdicho de alguno de ellos (es una constante últimamente: que nada es constante), aquí tienes otro documento oficial en GitHub que explica que algunas cosas que habían desaparecido han decidido incluirlas de nuevo.

Seriación binaria

Relacionado con lo anterior en cierto modo. La serialización (o seriación) binaria es "increíblemente compleja" (sic) y requiere un conocimiento íntimo de los tipos a seriar ya que incluye el estado de objetos internos y privados. En .NET Core no está soportada. Se recomienda usar tipos estándar de seriación como JSON, que no llegan a un nivel tan interno pero son suficientes para la mayor parte de las aplicaciones.

Dominios de aplicación

Los dominios de aplicación (o App Domain) en .NET siempre han sido un concepto importante. Son equivalentes dentro del CLI a un proceso en el sistema operativo. Es decir, son una forma de proporcionar un aislamiento entre distintos procesos de ejecución de una aplicación para conseguir mayor seguridad (no se puede acceder de unos a otros), estabilidad (un error que eche abajo uno no afecta a los demás) e independencia de versiones (cada uno puede ejecutar código en una versión de .NET diferente).

Aunque, casi por definición, la nueva .NET Core implementa dominios de aplicación para aislar sus procesos, estos no son accesibles en modo alguno para el programador, y específicamente el compilador a código nativo de .NET Core (.NET Native) no les da soporte ni se lo dará en el futuro debido a que es muy costoso en términos de rendimiento y recursos hacerlo (y .NET Core es todo acerca de esto, como ya hemos comentado).

Para aislar procesos dentro de nuestra propia aplicación deberemos usar la API de System.Diagnostics.Process. Si lo que quieres es cargar dinámicamente ensamblados, entonces hay una nueva clase para eso llamada AssemblyLoadContext.

Sandboxing

Tradicionalmente otra de las funcionalidades que se delegaban a .NET era el aislamiento y control de acceso a recursos. Es decir, es .NET el que controla si tenemos acceso a ciertos recursos como archivos en red, otras máquinas, el registro, etc...

En .NET Core esto se delega directamente al sistema operativo, que antes era una capa de control a mayores.

Remoting

Bueno, estaba claro que esta tecnología llevaba muchos años muerta. A pesar del bombo que se le dio en los inicios de .NET hace 15 años, la propia Microsoft reconoce que es una tecnología "problemática" (sic).

Para comunicaciones entre procesos de la misma máquina es mejor usar técnicas tradicionales como archivos mapeados en memoria o "pipes". Para comunicación entre máquinas, la Web API es tu amiga.

¿Qué APIs y funcionalidades de .NET no están soportadas en .NET Core pero quizá, algún día, en el futuro lo estén?

Del mismo modo que hay funcionalidad para la que no existen planes de migración o soporte, hay otras que si bien todavía no hay planes tampoco, no descartan que en el futuro quizá sí que estén soportadas. Según ellos mismos, "simplemente no hemos tenido tiempo de investigar si tendría sentido portarlo o no pensamos que sean relevantes para los modelos de aplicaciones que se ofrecen actualmente en .NET Core".

De todo lo que hay (que son muchas cosas) el equipo de .NET Core dice que son conscientes de que la gente les reclama todas estas cosas en GitHub:

  • System.Data: o sea, todo lo que es ADO.NET Clásico, que a pesar de Entity Framework sigue siendo muy popular por su sencillez de uso, potencia y universalidad para acceso a todo tipo de datos.
  • System.Transactions: no hay tampoco soporte para transacciones distribuidas. Muy relacionado con lo anterior.
  • System.DirectoryServices: para comunicación con Directorio Activo y directorios basados en LDAP en general. Una omisión importante en aplicaciones empresariales, en mi opinión.
  • System.Drawing: aunque esto ha estado tradicionalmente ligado a Windows Forms e interfaces de usuario de lado cliente, el poder manipular y pintar imágenes en memoria se usa mucho para generar al vuelo imágenes en el servidor y devolverlas. Tendrás que usar otra cosa para ello.
  • System.Net.Mail: para envío de correo. Tendrás que usar un servicio externo estilo SendGrid o Mandrill.
  • System.IO.Ports: nada de comunicación a través de puertos de serie, así que nada de conectarte a ciertos dispositivos de hardware.
  • System.Xaml: ya comentábamos antes que debes usar WinRT XAML, no el XAML tradicional de WPF.
  • System.Workflow: ah, pero ¿es que alguien usa Windows Workflow Foundation todavía?. Una tecnología prometedora en su día (y una virguería, la verdad) que se lanzó con .NET 3.5 como gran estrella junto a WCF y WPF, pero que se quedó en nada al igual que sus "hermanas". No creo que sea un gran problema para la mayoría, pero como dependas de ella que sepas que no podrás usar .NET Core.
  • Soporte de XSL y esquemas XML: pues eso: que sí hay soporte para XML (solo fastidiaría) y para XPath, pero nada de transformaciones XSL ni esquemas. Tampoco firmas digitales basadas en Xml. Vicisitudes de otra tecnología que en 2001 se vendía como el futuro pero que se han quedado en casi nada.

En GitHub tienes una lista de todas estas cosas y muchas más que la gente les reclama y que quizá algún día consideren portar. También dicen que, a lo mejor, alguna gente de la comunidad se anima a crear reemplazos de algunas de estas tecnologías que funcionen bajo .NET Core. Buena suerte con eso, aunque ahora es más fácil que nunca gracias a que el código completo de .NET (del actual también) es Open Source.

También hay otras que no se mencionan en ningún lado pero que no podrás hacer, como por ejemplo crear servicios o "demonios" del sistema.

Si hay alguna cosa que echas en falta en .NET puedes probar suerte y pedírsela también desde aquí.

¿Cómo puedo comprobar lo factible que es la migración de mi aplicación?

Bueno, antes de nada deberías hacer un análisis automatizado de tus ejecutables y DLLs. No hace falta el código fuente, solo los binarios.

Microsoft tiene una herramienta específica para esto: .NET Compatibility Diagnostic Tools.

Existe una versión de consola y un plugin para Visual Studio. Asegúrate de usar siempre la última versión pues .NET Core cambia de un día para otro.

La herramienta devuelve dos informes:

  • Resumen de alto nivel: te dice en cada uno de los ensamblados el % que creen que es portable directamente a .NET Core. Muchas veces las cosas simplemente se pueden cambiar un poco para que funcionen (como en Reflection). En otros casos no hay forma posible de arreglarlo.
  • Lista de APIs no-portables: de todo lo que usas te dice qué APIs no están soportadas por .NET Core.

Por cierto, la app que genera los informes también le pasa información anónima al equipo para saber qué aplicaciones hay por ahí que pueden no estar soportadas. Así que si te interesa especialmente que porten un API y la usas en alguna de tus apps, pásale la aplicación de análisis para que se den por informados también por esa vía.

Estrategias de migración

Al final del artículo oficial referenciado al principio hablan de diversas estrategias para portar tu aplicación a .NET Core, que básicamente son las obvias:

  • Co-evolución: básicamente que te quedes con tu aplicación actual en .NET tradicional y que vayas portando cosas concretas (o lo nuevo que hagas) a .NET Core.
  • Migración: usar todo lo anterior que hemos visto para migrar completamente la aplicación a .NET Core (sobre todo las que son apps Web, que deberían ser las más fáciles).
  • Empezar de cero: si no puedes migrarla y realmente tienes interés, empieza desde cero con .NET Core. Más te vale que la aplicación no sea muy grande en este caso, digo yo.

A mí, siendo malo, se me ocurre una cuarta opción: cambiarte de plataforma y empezar con NodeJS o Python. Y de hecho me consta que lamentablemente hay alguna gente que es la vía que ha tomado. Una verdadera pena por todos los años invertidos en .NET.

Para finalizar el artículo te ofrecen algunas indicaciones concretas más para la segunda y la tercera opción, pero nada que no se te ocurra a uno solo.

Existen unos cuantos enlaces al final del artículo que pueden resultar útiles.

¿Y tú qué opinas de .NET Core? ¿Vas a migrar alguna aplicación? ¿Te quedas para siempre con .NET clásico? ¿Te quieres cambiar de plataforma? Cuéntanoslo en los comentarios.

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.

Archivado en: Lenguajes y plataformas

Comentarios (15) -

bueno la alternativa no seria node.js o pyton, sino node.js o golang, que son los que están mas enfocados en la eficiencia, la velocidad y la utilización optima de recursos, que cada vez se vuelve el parámetro de mayor importancia en todo lo relativo a aplicaciones web.

Responder

En el aparado ¿Qué APIs y funcionalidades de .NET no están soportadas en .NET Core pero quizá, algún día, en el futuro lo estén?
Dices: "pero que se quedó en nada al igual que sus "hermanas""
¿A qué hermanas te refieres? ¿WCF y WPF?

Un saludo.

Responder

Existe alguna posibilidad a fecha actual para migrar apps tipo winforms fwk 4.0 a multiplataforma

Gracias

Responder

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

Hola Javi:

El proyecto Mono tiene un "clon" de Windows Forms llamado Mono WinForms que trata de facilitarte este proceso:

http://www.mono-project.com/docs/gui/winforms/

Pero no tiene toda la funcionalidad. Aún así se pueden migrar muchas aplicaciones desde hace años.

De hecho tienen una guía y un programa que analiza tu aplicación para decirte qué posibles problemas tendrás, etc...:

www.mono-project.com/.../

Saludos!

Responder

Muchas gracias Jose Manuel, por lo que veo com Mono solo apps C# y solo a linux.
Imposible a android o mac sin pasar por xamarin

Muchas gracias por tu tiempo

Salu2

Responder

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

Hola Javier:

De nada.

Con Mono Win Forms las apps también te funcionan en Mac, no solo en Linux.

Saludos.

Responder

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

Hola Joseba:

Sí, me refiero sobre todo a WCF, que a pesar de que sigue ahí, la verdad es que está en franco declive (o esa es la sensación que yo tengo).

Saludos!

Responder

Pues me dejas "meditabundo"...
¿Que tecnología o alternativa piensas que es o va mejor para servicios web? ¿Rest?

Gracias. Un saludo,

Responder

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

Para servicios web REST lo mejor que puedes usar es ASP.NET Web API. De hecho es lo que la propia Microsoft más está potenciando hace tiempo.

Saludos.

Responder

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

Y por cierto, yo soy un gran fan también de NancyFX:

http://nancyfx.org/

Es ligero, sencillo y funciona en Mono por lo que puedes generarlos para Linux o Mac sin tener que pasar a .NET Core.

Saludos!

Responder

Gracias por las respuestas.
Para terminar con el hilo, ya que tampoco pareces fan de WPF, ¿que propones como alternativa para este tipo de desarrollo?

Un saludo.

Responder

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

Hola Joseba:

No soy fan de WPF, pero porque realmente no me gusta ese tipo de desarrollo y nunca me he querido meter. Personalmente creo que Windows Forms va muy bien para aplicaciones de escritorio en Windows, está muy probado y hay miles de aplicaciones con esa tecnología que la refrendan. Pero entiendo que para otro tipo de interfaces, para apps con aspecto más moderno o para hacer algo multiplataforma no es lo mejor. Tampoco me gustó en su día los bandazos que dio Microsoft con la tecnología, primero con Silverlight, los cambios que metió, el "nuevo" WPF para apps universales que tampoco es exactamente igual a lo anterior...

Pero reconozco que es el futuro del desarrollo de UI con tecnología Microsoft y me consta que hay muchas empresas usándolo con éxito.

Yo, al ser desarrollador Web, no lo aprecio probablemente en su justa medida. Nada más :-)

Saludos!

Responder

Yo también soy mas del mundo web. Como .NET MVC me cae simpático voy a echarle un vistazo a WEB API 2 para el tema de servicios.

Gracias.

Responder

David Lopera
David Lopera

Muy buen artículo, muchas gracias. Solo una inquietud, actualmente para desarrollar aplicaciones orientadas a Workflows cual aconsejas ya que al parecer WWF no es una opción...Gracias!

Responder

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

Hola:

Windows Workflow Foundation forma parte de .NET Framework por lo que no va a desaparecer, sigue todavía en marcha y es una buena opción. Microsoft sí lo usa en varios de sus productos (BizTalk, AppFabric, TFS...) aunque sí es cierto que está más en mantenimiento que en desarrollo de nuevas funcionalidades, pero como digo no creo que vaya a desaparecer.

Si te refieres a usarlo con .NET Core: en ese caso, en efecto, no es una opción. Y lo siento, pero no conozco ninguna alternativa que recomendarte :-S

Saludos.

Responder

Agregar comentario