Archivo de la etiqueta: roslyn

¿Te gustaría que a VB.NET le añadan nuevas características en .NET 5 (.NET Core)? pues… vota esta petición

3 respuestas

Pues eso… que eso de que a los que preferimos VB sobre C# para crear nuestras aplicaciones (y aunque no lo prefiriéramos) no nos debería parecer bien que la gente de Microsoft haya decidido no añadir nuevas características al lenguaje, dejándolo estancado… es decir, que si bien podremos seguir usándolo no le van a añadir nuevas características. Por eso he publicado una petición en la comunidad de desarrolladores de Microsoft para ver si no lo dejan de lado.

—

Actualizado el 8-mar-2021

Esta es la respuesta de la gente de Microsoft (por Kathleen Dollar ex-MVP de Visual Basic que ahora trabaja en Microsoft):

Our strategy is here: https://devblogs.microsoft.com/vbteam/visual-basic-support-planned-for-net-5-0/

I do not think stabilizing the language blocks using new technologies in .NET 5.

Almost all new .NET 5.0 features are in the libraries and tools, which Visual Basic takes can use. Even features such ref struct which are not available in VB improve VB applications because they speed up operations in the BCL. And the BCL has a commitment to provide VB (and F#) friendly overloads for BCL features.

If there is a specific new feature, other than ref struct, that is blocking development, feel free to post a more specific issue.

Y de paso ha cerrado el hilo. Su respuesta es del 6 de enero de este año de 2021, aunque yo lo vi ayer, le respondí y Daniel Seara también y con más firmeza aún, jejeje

En fin… como le he contestado a Dani: Esto es lo que ahora nos podemos esperar los que usamos Visual Basic de la gente de desarrollo de Microsoft.

Es decir, ¡ahí te quedas, y búscate la vida!

En los enlaces que hay en el párrafo anterior están los enlaces a lo que comentó la gente del team de .NET sobre que Visual Basic no evolucionará como lenguaje aunque se podrá usar para generar aplicaciones de .NET 5.0 y .NET Core o .NET Standard (además de .NET Framework), pero te los repito: Visual Basic support planned for .NET 5.0 y la petición también la repito 😉 : Will be back Visual Basic evolve with C#?

Y la petición que yo te hago a tí que estás leyendo esto es que pinches en el enlace de la petición (este) y vote por esa petición, si te parece conveniente, claro, que tampoco te voy a obligar… ¡Faltaría más!

Y es que da la impresión de que los de Microsoft se han olvidado de todo (el dinero) que les ha dado Visual Basic (tanto para .NET como las versiones anteriores llamadas de forma genérica: VB6) y que lo abandonen de esa forma, mientras que F# si que seguirá evolucionando, que C# sea la estrella es porque está ligado 1 a 1 con el avance de .NET y por tanto debe seguir avanzando, tal como te expliqué en El porqué C# siempre tendrá novedades aunque Visual Basic ya no. Precisamente ahí te comenté lo que Anthony D. Green (un Program Manager de Visual Basic) opina sobre esto de que Microsoft no le dedique, al menos, la misma cantidad de persona que le dedica a F#, no, no tengo nada contra F#, solo que me extraña que un lenguaje que no usará ni la décima parte de la gente que usa VB.NET siga «palante» y VB no. Según ese señor, no sería necesario dedicarle más de tres personas (en nómina) aparte de los desarrolladores que quieran colaborar con el desarrollo (y la evolución) de Visual Basic. Si quieres, lee el artículo de Anthony y, aunque es un poco largo, deja muy claro las cosas.

Y ya no te canso más. Solo decirte que si te animas a votar favorablemente por la petición te explico cómo hacerlo:

Ve al sitio de Developer Community y accede a mi petición y pulsa en la flecha de arriba que está en la parte superior izquierda (ver la figura) para votar favorablemente, pero, por favor, no pulses en la flecha que señala para abajo, ya que quitarías votos… y no es plan 😉

Para votar a favor, pulsa en la flecha que señala para arriba. Gracias.

Agradecerte de antemano tu apoyo… y si quieres usar el hashtag (#evolvevb) pues mejor… que actualmente solo aparece un resultado y… no tiene nada que ver con evolucionar VB (que es lo que viene a significar evolveVB) 😉
Si quieres puedes usar #evolucionarVB para que todo quede en casa.

Por cierto, la Developer Community de Visual Studio está para añadir peticiones de nuevas características y para informar de bugs/fallos en Visual Studio y .NET.

Pues nada más… ¡gracias!

Nos vemos.
Guillermo

Compilar y ejecutar (utilidad para .NET)

Deja un comentario

Pues eso… esta utilidad la publiqué el 5 de enero de 2019, pero solo en elguille.info (Utilidades para .NET: Compilar y ejecutar) y aparte del código fuente puse la opción de instalarla usando ClickOnce.

En esa ocasión utilizaba código de Roslyn 2.0.1 (Microsoft.CodeDom.Providers.DotNetCompilerPlatform) para compilar el código desde la aplicación: se tomaba el código (un texto) de Visual Basic o C#, se compilaba y se mostraba el resultado por la consola virtual usada en la aplicación, de modo que pudieras ver el resultado de la salida.

Algo como lo mostrado en la siguiente captura, donde el panel superior es el código y el inferior es la salida al compilar y ejecutar dicho código.

 

El código de esa utilidad lo he cambiado con fecha del 30 y 31 de agosto de 2020, entre otras cosas para usar Roslyn 3.6.0, que actualmente es la versión más reciente.

Y el escribir esto aquí, en el blog, es para comentarte que al usar esa nueva versión del paquete de NuGet daba error al ejecutar el código (y pulsar en el botón de compilar).

El error era que no encontraba el compilador de Visual Basic (vbc.exe) o C# (csc.exe) y el path que daba era el path del ejecutable seguido de bin\roslyn, por ejemplo: «<resto del path>\bin\roslyn\vbc.exe»

Yo ya estaba por desistir y dejar la versión 2.0.1 de Roslyn ya que al fin y al cabo me permitía usar la versión más reciente de los compiladores de VB y C#, pero buscando en el NuGet del CodeDom.Providers.DotNetCompilerPlatform de Roslyn 3.6.0 y concretamente al mirar en el enlace que hay debajo de «This package was built from the source at» me llevó al GitHub de aspnet / RoslynCodeDomProvider. Y mirando en las Issues (había 3) me topé con la de WolfgangHG con el título: [3.6.0] Missing entry «aspnet:RoslynCompilerLocation» in app.config causes compile to fail, y eso era todo lo que hacía falta… añadir un trozo de código que en teoría faltaba para que funcionara a la perfección (ese código si se incluye en roslyn 2.0.1) y es este:

  <appSettings>
    <add key="aspnet:RoslynCompilerLocation" value="roslyn"/>
  </appSettings>

Y ya si quieres, cambia la asignación de compilerOptions de C# y VB (en la sección system.codedom / compilers) para que la versión del compilador sea la predeterminada: /langversion:default. Ya que en mi caso, la versión de C# estaba en la 7.3 y se puede usar la 8.0. Con Visual Basic, la «default» es la versión 16 (la última hasta la fecha de hoy).

En la siguiente captura puedes ver las versiones que aceptan los compiladores vbc.exe y csc.exe en el Roslyn 3.6.0:

Versiones de los lenguajes de VB y C# soportadas por los compiladores incluidos en Roslyn 3.6.0

Como ves, la versión predeterminada (y la mayor) de vbc.exe en la 16, mientras que la del compilador de C# (csc.exe) es la 8.0.

NOTA:
En la preview de Visual Studio 2019 la versión más alta de C# es la 9.0, la de VB sigue siendo la 16.

Nota:
Desde la página de la utilidad en elguille.info puedes instalarla con ClickOnce y tienes el código fuente de la utilidad (en Visual Basic) y algunos ejemplos tanto en VB como en C#.

Nos vemos.
Guillermo

Compilar y ejecutar

Deja un comentario

Compilar y ejecutar es una utilidad creada con WPF (.NET 4.7.2) para compilar y ejecutar aplicaciones tipo consola desde la misma aplicación. Permite guardar el código de VB y C# así como la salida de la consola. Permite colorear el código (tanto de VB como el de C#) y tiene algunos trucos para redirigir la salida de un ejecutable, sincronizar el contenido de dos TextBox, añadir y recuperar texto (o el contenido) de un RichTextBox, y más…

Para compilar utiliza Roslyn 2.0.1 (Microsoft.CodeDom.Providers.DotNetCompilerPlatform) de esta forma permite el uso de código para compilar con C# 7.3 y VB 15.5 ya que el compilador predeterminado de CodeDom es para las versiones 5 de C@ y 11 de Visual Basic. Por tanto, puedes usar Tuplas si quieres Winking smile

En la figura 1 puedes ver la aplicación en ejecución con un código de Visual Basic coloreado, mostrando la salida de la aplicación (de consola).

Figura 1. La aplicación en funcionamiento
Figura 1. La aplicación en funcionamiento

En la salida por la consola las vocales acentuadas (con tildes) no se mostraban bien y he usado un truco para convertir el texto de la consola de forma que se pueda leer sin problemas, concretamente usando la codificación de la página de códigos 437 usando GetEncoding(437).

Este es el código (para VB) que hace la conversión de lo leído por la salida estándar de un objeto Process y convirtiéndolo en texto (un truco para convertir un MemoryStream en texto o cadena).

' Convertir la salida usando el código de página 437
' que es la usada en MS-DOS (línea de comandos)
Dim texto = p.StandardOutput.ReadToEnd()
Dim ms As New MemoryStream(ASCIIEncoding.[Default].GetBytes(texto))
texto = Encoding.GetEncoding(437).GetString(ms.ToArray())

En otra ocasión te explicaré con más detalle todas las cosillas que la aplicación hace, por ahora te dejo el zip con el código fuente de Visual Basic en una solución para Visual Studio 2017 además del ejecutable y si prefieres instalarla usando ClickOnce, también lo puedes hacer, más abajo tienes los enlaces.

Comentarte que en el ZIP se incluye los packages de Roslyn.

Y esto ews todo por ahora… Smile

Espero que te sea de utilidad

Nos vemos.
Guillermo

P.S (27-feb-2021 15:19)
No sé porqué esto lo tenía como borrador… seguramente porque no estará completa la entrada, pero… así la dejo 😉