Archivo de la etiqueta: c#

El porqué C# siempre tendrá novedades aunque Visual Basic ya no

Pues eso… el otro día estaba leyendo un artículo de Anthony D. Green (miembro del team de Visual Basic de Microsoft del 2010 al 2018) sobre todo lo relacionado con la que se lio por el tema de que a Visual Basic no se le añadirán nuevas características, (
Future features of .NET Core that require language changes may not be supported in Visual Basic.), pero no es de eso de lo que te quiero hablar aquí. Es de lo que dice Anthony en su artículo.

Concretamente esta parte es la que me ha hecho reflexionar un poco sobre C#:

C# advances the .NET platform.
I’m not begrudging or envying them that role but recognizing that that’s what the language has always done where VB is traditionally focused on innovation in experience.
It’s not that you can’t write a library or a framework in VB (and people have) but the .NET platform is not and will never be dependent on the VB language (or F#) to make leaps.
But if C# is late developing generics, .NET 2.0 doesn’t ship.
If C# hasn’t figured out the shape and behavior of nullable value types those types can’t appear in any new APIs.
If it’s late on LINQ, .NET 3.5 doesn’t ship.
If async isn’t complete, .NET 4.5 can’t ship with new asynchronous APIs.
If C# language design can’t converge on ref returns or nullable annotations the platform teams (like mscorlib) that depend on those features literally cannot ship their platforms for anyone.
And for what it’s worth, C# is ALWAYS late on those things (a fact I learned too late) because getting it right takes all the time in the world.
Which is why it’s insane (in hindsight) to envision an “ideal” world where you couple or serialize a language which does not fulfill that mission critical role with so many downstream dependencies and its customers’ productivity with one that does and expect good things for both of them.

Extracto de: Un manual sobre por qué el sufrimiento crónico de la comunidad de VB.NET no es necesario ni una cuestión de gastos o practicidad

Es decir, C# tiene que estar siempre actualizado ya que la plataforma .NET depende de C# (o casi). El casi es porque es el lenguaje de .NET que Microsoft tiene para poder usar las novedades que se agreguen a .NET.

Y como ahora .NET ya no será una continua actualización de .NET Framework, si no de .NET Core (multiplataforma), es lógico que también deba incorporar las novedades enfocadas a ser utilizado tanto en Windows como en MacOS, Linux, iOS, Android, etcétera.

¿Debo olvidarme de Visual Basic y pasarme a C#?

Esto no significa que a Visual Basic no se le deba seguir añadiendo nuevas características en el lenguaje, que según dice Anthony en su artículo es posible hacerlo si Microsoft dedica un par de profesionales a seguir manteniendo el lenguaje, que de otra parte puede recibir ayuda de la comunidad, como ya lo ha hecho con la última incorporación al lenguaje: Comentarios permitidos en más lugares dentro de las instrucciones que precisamente la ha agregado un participante de la comunidad: Paul1956 (Paul M Cohen).

Lo que sí tendrá Visual Basic son nuevas funcionalidades en el editor de Visual Studio (ver figura 1), pero no tendrá, por ejemplo el equivalente a record (registro) o init (establecedor de solo inicialización) en las propiedades.

Figura 1. Mostrar Inline parameters (parámetros en línea)

Así que… si quieres tener un lenguaje de programación para .NET que esté siempre actualizado a las novedades de la plataforma .NET, debes decantarte por C#.

Si no te gusta programar en C# pero sí en Visual Basic, recuerda que este último se quedará estancado en la versión 16.0, mientras que C# seguirá avanzando.
Eso no significa que no puedas seguir usando Visual Basic.

Pero si eres de los que quiere usar .NET 5.0 o las versiones que sigan apareciendo (cada año habrá una nueva y por tanto tendrá cosas nuevas), recuerda que podrás hacerlo, pero con las cosas que actualmente tiene Visual Basic.

Y si eres de los que no quieren usar nada relacionado con .NET / .NET Core / .NET Standard, podrás seguir usando Visual Basic en .NET Framework 4.8 (o anteriores), aunque este último seguirá estando disponible mientras Windows exista.

Resumiendo:
No te quedarás obsoleto si sigues usando Visual Basic. Pero si quieres poder usar en tu código las novedades agregadas a .NET tendrás que plantearte el cambio a C#, aunque sea para poder crear alguna biblioteca de clases que utilice esas novedades de .NET y las pongas a disposición de tu código de Visual Basic (la cuestión es querer arreglar las cosas 😉 ).

Aprender C#

Y si quieres pasarte a C#, ya sabes que en elGuille.info (y en este blog) tienes un montón de código en C# con su equivalente en Visual Basic (o viceversa), ya que desde enero de 2001 (sí, hace ya 19 añitos de nada) todo (o prácticamente todo) lo que he ido publicando para Visual Basic (trucos, API, utilidades, WPF/XAML, etc.) está con el código para los dos lenguajes. Y, lo más importante: ¡TODO GRATIS! (aunque también puedes hacer una donación con PayPal 😉 ).

Por supuesto también puedes apuntarte a algunos de los muchos cursos que hay en las plataformas de enseñanza online y aprender (pagando) el lenguaje C#.

Cómo lo hagas, si decides hacerlo, es cuestión tuya.

Por mi parte, seguiré usando Visual Basic como lenguaje de programación principal, sin olvidarme de C# e ir aprendiendo las cosas nuevas que vayan apareciendo.
Tanto de uno como de otro lenguaje, iré publicando artículos para que te sirva de aprendizaje o para que te aclares un poco más

En un próximo artículo te explicaré algunas de las novedades de C# 9.0 como son los tipos de registro (record), inicializadores en las propiedades (init) o instrucciones de nivel superior (Top-level statements).

Nos vemos.
Guillermo

P.S.
Traducción (automatizada del párrafo en inglés):

C# avanza la plataforma .NET.
No les estoy regateando ni envidiándoles ese papel, pero reconozco que eso es lo que siempre ha hecho el lenguaje, donde VB se centra tradicionalmente en la innovación en la experiencia.
No es que no pueda escribir una biblioteca o un marco de trabajo en VB (y la gente lo ha hecho), pero la plataforma .NET no depende y nunca dependerá del lenguaje VB (o F #) para avanzar.
Pero si C# desarrolla genéricos tarde, .NET 2.0 no sale.
Si C# no ha descubierto la forma y el comportamiento de los tipos de valores que aceptan valores NULL, esos tipos no pueden aparecer en ninguna API nueva.
Si llega tarde en LINQ, .NET 3.5 no se distribuye.
Si async no está completo, .NET 4.5 no se puede enviar con nuevas API asincrónicas.
Si el diseño del lenguaje C# no puede converger en devoluciones de referencia o anotaciones que aceptan valores NULL, los equipos de la plataforma (como mscorlib) que dependen de esas características, literalmente, no pueden enviar sus plataformas a nadie.
Y por si sirve de algo, C# SIEMPRE llega tarde en esas cosas (un hecho que aprendí demasiado tarde) porque hacerlo bien lleva todo el tiempo del mundo.
Es por eso que es una locura (en retrospectiva) imaginar un mundo «ideal» en el que se acopla o serializa un lenguaje que no cumple esa función crítica con tantas dependencias posteriores y la productividad de sus clientes con uno que sí y espera cosas buenas para ambos.

Fallo en el editor de código de VB y C# en Visual Studio 2019

Pues eso… estaba yo tan tranquilo escribiendo código en un formulario de Windows Forms cuando pasé al diseñador a mirar algún evento o nombre de un control y cuando volví al código… ¡HABÍA DESAPARECIDO!

Noté que después de cambiar del diseñador al panel de código el asterisco (*) de modificado había desaparecido… Y (seguramente) la posición en el editor de código era la misma que cuando abrí el proyecto. Así que… me puse puse a buscar lo que había escrito (por si se hubiese cambiado la posición dentro del editor) y ¡el código no estaba!

Era raro… muy raro…

Menos mal que se me ocurrió darle al botón DESHACER. ¡Y el código volvió a aparecer! (Y el asterisco de modificado también).

Todo esto era en un proyecto para Visual Basic usando Visual Studio 2019 Community «normal», aunque después probé en la Preview y también ocurre.

El problema

Para un ejemplo de lo que ocurre ver el GIF animado de la figura 1 para que te hagas una idea.

Figura 1. Fallo en el editor de formularios de Visual Studio 2019 usando Visual Basic

Lo de mostrar la versión de Visual Studio es porque este GIF (y los que te voy a mostrar después) los mandé la notificación del problema a la comunidad de desarrollo (Developer Community).
Ya que ellos (después de explicarles varias veces los pasos a seguir) no consiguieron reproducirlo y en sus capturas me mandaban la versión de Visual Studio que estaban usando.

 

Nota del 18/Sep:
Dicen que lo están investigando:
This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.
A ver qué ocurre…

 

Los pasos a seguir, al menos así es como me ocurría más a menudo (aunque no siempre ocurría) son estos:

1- Con cualquier proyecto de Visual Basic (al principio pensé que solo ocurre en VB, pero después comprobé que también ocurre en C#) deja abierto el formulario en modo de diseño y la ventana de código, de forma que el código tenga el foco antes de cerrar la solución (o el Visual Studio).
2- Al abrir nuevamente Visual Studio, te mostrará la ventana de código.
3- Escribe lo que sea y pasa a la ventana del diseñador de formularios.
4- Vuelve a la ventana del editor y verás que el código antes escrito desaparece.
5- Si lo quieres recuperar, tendrás que pulsar en el botón de deshacer.
5a- En al menos una ocasión (creo que con la versión Preview y un proyecto de C# para .NET 5.0 Preview 8) mostró un aviso de que se perderán los cambios en el diseñador (o algo así, no le presté atención ya que no pensaba que iba a ocurrir esto de perder el código), pero al darle varias veces a deshacer, el código volvió.

Pruebas y más pruebas

Este problema no ocurre siempre, ese es realmente el problema.

Para comprobar los fallos (y porque los de Microsoft me pidieron que les enviara un proyecto en el que ocurriera) creé un nuevo proyecto de Windows Forms para Visual Basic con .NET Framework 4.7.2 y, tras varias pruebas, se reprodujo el problema.

También probé con proyectos de C#, tanto con la versión normal de Visual Studio como con la versión Preview. Pero no era capaz de que volviese ocurrir en C#, pero sí en VB. Así que… pensé que solo ocurría esto en los proyectos de los pobres y ya casi abandonados usuario de Visual Basic.

Pero no: El problema también ocurre con proyectos de C#.
Más sobre esto dentro de un momento.

Usar una máquina virtual en Azure preparada para Visual Studio 2019

Los de Microsoft (concretamente John Q., me preguntaron si esto mismo me ocurría en otros equipos o le ocurría a otros desarrolladores de mi equipo… ¡sic! ¡Solo tengo a un desarrollador en mi equipo! Y no, no tengo otros equipos (máquinas) en la que poder probarlo… Se me ocurrió que podría probarlo en una máquina virtual… Pero me daba pereza crear una máquina virtual, instalar el Visual Studio y probarlo, así que… se me ocurrió probarlo en una máquina virtual de Azure.

Me creé una cuenta «FREE» de Azure (la que yo tenía ya caducó hace meses) con idea de usar allí una máquina virtual, pero la pereza era la misma… tener que crear una máquina virtual y tener que instalar el Visual Studio.

Sé que hay (o al menos había) máquinas virtuales ya preparadas con Visual Studio y que Microsoft las pone a nuestra disposición, así que… me puse a buscarla y encontré esto en la documentación de Microsoft: Imágenes de Visual Studio en Azure.
Uno de los enlaces activos era este: Visual Studio 2019: versión más reciente (16.5), pero el enlace estaba roto y no mostraba nada (salvo un error 404).

Así que… usé el enlace para Azure Marketplace (en la misma página de las imágenes de Visual Studio en Azure) y también daba error 404. Pulsé en el enlace de esa misma página que indica Ir a Azure Marketplace y con un poco de paciencia la página apareció) y entré en el apartado Apps. Filtré para que me mostrase solo las de Microsoft como publisher para el sistema operativo Windows y el tipo de producto Virtual Machine Images.

Y allí estaba: Visual Studio 2019 Latest.

Figura 2. La máquina virtual de VS para Azure


Al pulsar el enlace (no me deja copiarlo) muestra una ventana pop-up con las opciones que hay para seleccionar, primero seleccioné la versión Community para Windows 10, pero no me dejó instalarla, así que… posteriormente elegí la versión Visual Studio 2019 Comunity (latest release) on Windows Server 2019 y esa sí funcionó.

Probando a repetir el problema con Visual Studio en la máquina virtual de Azure

Allí probé el proyecto que les mandé y tras no-se-cuantas-miles-de-pruebas, el problema no se repetía.

Lo más que me ocurrió fue algo que también me ha ocurrido más veces (y seguramente tendrá que estar en una nuevo problema para que lo resuelvan) y es que al pasar o mostrarse directamente la ventana de código al abrir el proyecto, esta se muestra totalmente en blanco, tal como puedes comprobar en la figura (GIF) número 3.

Figura 3. Cuando te quedas en blanco mientras escribes código… o casi 😉

Pero el fallo inicial no se reproducía en el proyecto de prueba de Visual Basic.

El problema también ocurre con proyectos de C#

Así que… me dio por crear un nuevo proyecto de C# para Windows Forms usando .NET Core 3.1, así de paso probaba qué características tiene ese tipo de proyecto, ya que con los de Visual Basic para .NET 5.0 Preview 8, son una caca… también para C#, ya que no puedes hacer casi nada en el diseñador de formularios, al menos no puedes enlazar los eventos ni editar visualmente los menús, etc., pero esa es otra historia.

Y el fallo volvió a ocurrir… ya no recuerdo si fue a la primera o a la segunda… y eso que fue ayer… la cuestión es que funcionó y yo tenía la utilidad ScreenToGif lista para capturar los movimientos.

Y los capturé, y en la figura 4 puedes ver que con un proyecto de C# también ocurre.

Figura 4. El fallo de perder lo escrito en un proyecto de C#

Fíjate en el detalle de que antes de mostrar el diseñador de formularios aparece un mensaje indicando algo como Opening the file… si eso se muestra… ¡es prácticamente seguro que el fallo va a ocurrir!

 

Y esto es todo… a ver si lo solucionan.

Lo que si es cierto es que hay más cosas que pasan, aparte de que escribas código y se pierda o se quede la ventana de código en blanco, ya que también me ocurre que estando en el diseñador de formularios no se muestra la ventana de propiedades y tengo que cambiar a otra pestaña o cerrar y abrir el formulario para que por fin se muestre la ventana de propiedades o que al estar en la ventana de propiedades, en el despegable donde indica qué control estás mostrando esté en blanco y aún así se muestren algunas propiedades… esto último me pasó en el proyecto de C# para .NET Core 3.1 en el que tenía seleccionado un botón que quería moverlo o cambiar el valor de la propiedad Anchor y al no mostrarse esa propiedad pensé que en .NET Core 3.1 no existía esa propiedad… y no, era que fallaba la ventana de propiedades.

Si te ha ocurrido algo de esto, por favor indícalo en la página esa de Developer Community en la que he publicado el fallo (la descripción del problema está en inglés), te repito el enlace para que te sea más cómodo:

When opening a project if I modify the code and then (without saving) I show the form, when returning to the code that code does not exist (any changes made are not shown).

Es un título largo, lo sé… pero… 😉

Gracias.

Nos vemos.
Guillermo

gsCompilarNET: una biblioteca de clases para compilar código de C# o VB

Pues eso… intentando convertir la utilidad de Compilar y ejecutar a .NET 5.0 (Preview 8) me topé que (si no recuerdo mal) el .NET 5.0 no ofrece las clases para compilar (Microsoft.CodeDom.Providers.DotNetCompilerPlatform), así que… me puse a buscar en la web y me topé con un código de ejemplo (en C#) de Laurent Kempé que estaba escrito usando .NET Core 3.0 Preview 2.

Me puse a copiar el código que tenía publicado en el artículo y lo modifiqué para crear un proyecto para .NET Core 3.1 que usara las clases de compilar y ejecutar (Compiler y Runner) desde otra clase estática que es la encargada de llamar compilar y ejecutar el código. Después descubrí que ese código lo tenía publicado en GitHub, pero en realidad ya lo tenía copiado/adaptado usando el código de su web.

El problema inicial con el que me encontré es que solo compilaba código de C#, así que… lo modifiqué para que también compilara código de Visual Basic.

En principio ese código solo compilaba/ejecutaba código de consola. Así que… tuve que modificarlo para que también compilara código de Windows Forms, eso sí, todo el código debía estar en un solo fichero.

La respuesta a esto último que me dio la idea de cómo solucionarlo (o casi) la encontré en la red, pero no recuerdo en qué página, solo sé que era para ejecutar código de Visual Basic contenido en una base de datos, pero en realidad no era para código de Windows Forms, si no de consola, pero eso me sirvió para (además de agregar las referencias necesarias) poder crear el fichero json que necesita dotnet para crear el tipo adecuado de aplicación o usar las bibliotecas necesarias, la verdad es que tampoco me enteré demasiado… solo que haciéndolo, funcionaba 😉

La cuestión es que conseguí hacer operativo el compilador para usar código de Visual Basic (y C#) tanto para consola como para formularios de Windows.

Este es el código (o parte) que hace que esto sea posible:

        ' para ejecutar una DLL usando dotnet, necesitamos un fichero de configuración
        Dim jsonFile = Path.ChangeExtension(outputExe, "runtimeconfig.json")
        Dim jsonText = ""
        If compiler.EsWinForm Then
            Dim version = Compiler.WindowsDesktopApp().Version
            ' Aplicación de escritorio (Windows Forms)
            ' Microsoft.WindowsDesktop.App
            ' 5.0.0-preview.8.20411.6
            jsonText = "
{
    ""runtimeOptions"": {
    ""tfm"": ""net5.0-windows"",
    ""framework"": {
        ""name"": ""Microsoft.WindowsDesktop.App"",
        ""version"": """ & version & """
    }
    }
}"
        Else
            Dim version = Compiler.NETCoreApp().Version
            ' Tipo consola
            ' Microsoft.NETCore.App
            ' 5.0.0-preview.8.20407.11
            jsonText = "
{
    ""runtimeOptions"": {
    ""tfm"": ""net5.0"",
    ""framework"": {
        ""name"": ""Microsoft.NETCore.App"",
        ""version"": """ & version & """
    }
    }
}"
        End If
        Using sw = New StreamWriter(jsonFile, False, Encoding.UTF8)
            sw.WriteLine(jsonText)
        End Using

Hoy me ha dado por convertir el código de C# (ya modificado y operativo) a Visual Basic y he creado un «repositorio» en GitHub con el código de la DLL que he creado para compilar código.

También he publicado el código de la versión de C#, ya que actualmente tengo las dos versiones sincronizadas (es decir, los cambios y mejoras que he añadido en VB los he pasado al proyecto de C# y viceversa).

Así que… si te interesa el código de esta DLL para compilar puedes descargarlo/verlo en el repositorio de GitHub para gsCompilarNET.

Después publicaré también la utilidad de .NET 5.0 para Windows Forms que utiliza esa DLL (y la de gsColorearNET).

 

Espero que te sea de utilidad. 🙂

Nos vemos.
Guillermo

P.S.
He publicado en NuGet la utilidad ya compilada por si quieres usarla en tus proyectos de Visual Studio (final o preview):
gsCompilarNET en NuGet.

P.S.2
Esta es la pagina original de Compilar y ejecutar en elGuille.info (para .NET Framework 4.7.2 usando WPF).