elGuille mola

Etiqueta: Visual Studio

Posts relacionados con el entorno de desarrollo (IDE) de Visual Studio

  • Compilar y ejecutar versión para .NET Core (.NET 5.0)

    Nota del 26-oct-2020:
    Esta utilidad (seguramente) no tendrá más actualizaciones.
    En su lugar he publicado otra más completa en github: gsEvaluarColorearCodigoNET que incluye evaluación del código, compilar, compilar y ejecutar (por ahora para un solo fichero), colorear y colorear en HTML y tiene cosas interesantes para la creación de un editor de múltiples ficheros con algunas utilidades más.
    Cuando tenga la página publicada en el blog, te dejaré el enlace.

     

    Pues eso… siguiendo las pruebas de crear proyectos de .NET Core (con .NET 5.0) para Visual Basic, aquí traigo el de Compilar y Ejecutar que está creado con WPF / XAML y que además usa la biblioteca de clases para colorear (gsColorearCore) que también he convertido para .NET Core, en esta ocasión para la versión 3.1.

    La he convertido para usar con .NET 5.0 (.NET Core), más que nada para probar, pero visto lo visto (los problemas) prefiero quedarme con la versión de .NET Framework.

    Nota:
    Abajo tienes una actualización del 16/Sep/2020

     

    ¿Por qué es preferible usar .NET Framework para este tipo de aplicación?

    Por la sencilla razón de que salvo cosas puntuales, no tiene mucho sentido hacerla para .NET Core. Ya que este tipo de aplicaciones (las creadas para WPF o Windows Forms) solo se ejecutarán o funcionarán en equipos que utilicen Windows como sistema operativo.

    Que tú prefieres usar el .NET Core porque «DICEN» que es más rápido, ocupa menos, se puede «embeber» con la aplicación y otras monerías… pues muy bien… lo mismo yo utilizo esas cosas «puntuales» para hacer algo con .NET 5.0, o hacer mucho cuando ya sea .NET 6.0, el tiempo lo dirá… No hay que descartar nada ni decir de este agua no beberé 😉

    Cosas a tener en cuenta en la migración de .NET Framework a .NET Core

    Aparte de que hay ciertas cosas que ya no existen, al menos de la forma a la que estamos habituados en las aplicaciones para .NET Framework, el resto no cambia nada o no cambia mucho.

    Configuración (My.Settings)

    Por ejemplo, me he encontrado con problemas a la hora de usar My.Settings. Me estuvo funcionando y de buenas a primeras dejó de hacerlo, así que… corté por lo sano y me deshice de My.Settings y las configuración la uso por mi cuenta, concretamente usando la clase Config que tengo definida en la DLL de gsColorear.

    No quiero decir con esto que no se puedan usar… solo digo que a mí me estuvo funcionando bien hasta que de buenas a primeras dejó de funcionar.

    Propiedades del proyecto

    A las propiedades del proyecto ya no accede desde el nodo MyProject.
    Ahora puedes hacerlo pulsando en el nombre del proyecto con el botón secundario del ratón (normalmente el derecho) y del menú mostrado pulsar en Propiedades (ver la figura 1).

    Figura 1. Acceder a las propiedades del proyecto

    NOTA:
    Si simplemente haces clic en el nombre del proyecto (y la ventana de propiedades no estaba abierta anteriormente y ocasionalmente si también está abierta) se mostrará el fichero .vbproj con las opciones de configuración en formato XML no con tantas «cosas» como el de una aplicación para .NET Framework (ver la figura 2).
    Ahí, entre otras cosas, se indica la versión del .NET Core que estás usando (en este caso .NET 5.0 para Windows), qué tipo de aplicación es, el espacio de nombres, etc.

    Figura 2. Propiedades del proyecto en XML

    Este es el aspecto (simplificado) de la ventana de propiedades del proyecto (ver figura 3).

    Figura 3. Ventana de propiedades del proyecto

    Si pulsas en Paquete (en el panel izquierdo de la ventana de Propiedades) tendrás algo parecido a la información del ensamblado de las aplicaciones para .NET Framework.

    Referencias

    Las referencias a DLL externas (u otros proyectos), se pueden hacer desde la ventana de propiedades, pero en la ventana del explorador de soluciones ya no se muestra como el nodo Referencias. Ahora está en Dependencias.

    Si pulsas en Referencias de la ventana de propiedades, verás que está vacía, pero puedes agregar las referencias que necesites, supongo que, a diferencia de una aplicación de .NET Framework, aquí solo tienes que añadir las referencias externas, es decir, las que no se encuentren ya definidas en el propio .NET Core.

    En realidad en Dependencias añadirás las mismas cosas que antes (con .NET Framework) añadías en tu proyecto: paquetes NuGet, referencias a otros proyectos, etc.

    En el caso de las referencias a otros proyecto, están en un nodo diferenciado (Proyectos), tal como puedes comprobar en la figura 4.

    Figura 4. Nodo de proyectos usados en el proyecto actual

    Y básicamente estos es lo diferente… y eso que no me he puesto a añadir configuraciones ni recursos desde la ventana de propiedades… pero eso lo dejo estar… al menos por ahora 😉

     

    Todo esto lo estoy escribiendo el 5 de septiembre de 2020 y estoy usando Visual Studio Community 2019 Preview Versión 16.8.0 Preview 2.1 con el .NET 5.0 versión 5.0.100-preview.8.20417.9.

    Para estas pruebas he copiado el proyecto para WPF Compilar y ejecutar versión 1.0.0.21 del 31 de agosto de 2020 con la librería gsColorear2008 versión 1.0.6.3 del 8 de enero de 2019.

    Nota:
    Me apunto actualizar la página de gsColorear en mi sitio para que tenga la última versión tanto de la DLL como de la aplicación.

    En la librería de colorear el código, también tuve que quitar los ficheros de recursos (con las palabras clave de los lenguajes) y guardarlos (y abrirlos al usarlos) de forma manual en vez de como si fuese un recurso. No fue complicado, pero… es otra cosa que rompe la compatibilidad entre proyectos. Y esto es independiente de la versión de .NET Core que tenga asignada en el proyecto, ya que lo probé inicialmente con el .NET 5.0 y después con el .NET Core 3.1.
    Al final lo he dejado con el .NET Core 3.1, ya que al ser una biblioteca de clases, .NET Core 3.1 si da soporte a ese tipo de proyectos de Visual Basic.

     

    Y esto es todo por hoy… otro día más…

    Espero que te haya sido de utilidad.

     

    Actualización del 16/Sep/2020

    He actualizado el código, tanto de la utilidad de compilar y ejecutar como de la DLL de compilar, esta última ahora usa código de Visual Basic en lugar de C#, y también he actualizado la DLL de colorear el código.

    Todos esos cambios están en el repositorio de gitHub de gsCompilarEjecutarNET.

    Además, he convertido el código de la utilidad a C# y también está publicado en gitHub.

     

    Aquí te dejo el enlace original al código que puse cuando publiqué este artículo originalmente el 5 de septiembre.

    El enlace para descargar los proyectos Compilar y ejecutar y gsColorearCore para .NET Core

    ZIP: Compilar_ejecutar_NetCore_20200905_1710.zip (70.8 KB)
    MD5 checksum: ACDC9EF7E2C0F4469719F06D88F8F812

     

    Nos vemos.
    Guillermo

  • Tips para crear proyectos de .NET Core (.NET 5.0) en Visual Studio 2019 Preview

    Pues eso… leyendo el otro día el artículo Visual Basic support planned for .NET 5.0 (soporte planeado en .NET 5.0 para Visual Basic) indicaba una serie de tipos de proyectos, entre ellos de Windows Forms y WPF, pero no solo para Windows y usando el .NET Framework (que es lo que dicen por ahí que será lo que nos quede en un futuro a los que preferimos usar Visual Basic en lugar de C# (u otro lenguaje de .NET).

    Así que… abrí el Visual Studio 2019 (Community) Preview (v16.8.0 Preview 2) y me puse a mirar los tipos de proyectos que había… para C# había de esos dos tipos de aplicaciones tanto para .NET Core como para .NET Framework, pero para Visual Basic solo era para este último marco de trabajo.

    Mirando la configuración de los ficheros del proyecto de C# pude crear un proyecto de Windows Forms para Visual Basic que usa el .NET 5.0 basándome en uno de consola (de esos si que hay para el .NET Core o el .NET 5.0).

    ¡Y funciona!

    El problema, es que al agregar los controles al formulario y crear los métodos de evento (haciendo doble-pulsación en el control), los métodos de evento se creaban, pero no estaban conectados con los controles. Y eso es porque al crear los controles (añadiéndolos al formulario) no se definían con WithEvents.

    La solución es fácil, se abre el fichero Form1.Designer.vb, se modifica la declaración de los controles (que suelen estar al final de ese fichero) y asunto arreglado… bueno, si le añades el típico Handles después de la declaración del método, por ejemplo:

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    Label1.Text = "¡Hola Mundo!"
End Sub

    Esto último es lo menos engorroso de hacer… lo complicado (o tedioso) es convertir ese proyecto de consola a uno de Windows Forms.
    ¡Y no te voy a explicar cómo hacerlo! 🙂
    No, ya que no es necesario hacer nada si sigues el consejo que te daré a continuación.

    Crear proyectos de Visual Basic para .NET Core (o .NET 5.0)

    Si no quieres complicarte mucho la vida, haz lo siguiente (tal como se muestra en la figura 1):

    Selecciona el menú de Herramientas>Opciones y se muestra la ventana de configuración, selecciona Entorno>Características en versión preliminar y ahí marca la casilla Mostrar todas las plantillas de .NET Core en el cuadro de diálogo nuevo proyecto y pulsa Aceptar. Tendrás que cerrar y abrir nuevamente el Visual Studio y ya tendrás todas las plantillas que hay actualmente disponibles.

     

    Usar los nuevos tipos de proyectos

    Si ahora creas un nuevo proyecto (o agregas uno a una solución existente) verás que ya están los proyectos de Visual Basic para todas las plataformas (usando Windows Forms y WPF entre otros).

    Una vez que seleccionas uno de los proyectos para «todas las plataformas» te dará la opción de elegir la plataforma de destino (el «framework» que usarás). (ver la figura 3)

    Si eliges una aplicación de WPF te mostrará las 3 opciones de la figura anterior, si eliges una aplicación de Windows Forms, solo mostrará .NET Core 3.1 y .NET 5.0.

     

    NOTA:
    Como sabrás .NET 5.0 es una especie de remix entre el .NET Framework y el .NET Core o lo que es lo mismo, es la continuidad de .NET Core, pero unificado con el .NET Framework.
    Y la primera versión definitiva está planeada para noviembre de este año de 2020.

     

    ¿Se soluciona algo al crear así las aplicaciones de Windows Forms?

    Pues no… o casi… Me refiero a que al añadir un control al formulario y hacer doble-clic en él se genere correctamente el método de evento.

    Ni usando el .NET Core 3.1 ni usando el .NET 5.0 (al menos en Visual Basic) se generan correctamente esos métodos de evento.

    Si usas .NET Core 3.1 como plataforma de destino, al menos se definirán los controles con WithEvents, pero tendrás que añadirle el Handles o enlazar el evento y el método con AddHandler.

    Si usas como plataforma de destino el .NET 5.0, no se definen los controles con WithEvents y, por tanto, tampoco se crean los métodos con Handles ya que es un requisito el que las variables (controles en este caso) estén definidos con WithEvents para permitir definir los eventos con Handles.

     

    A esperar toca…

    Esperemos que en futuras revisiones del .NET 5.0 o de Visual Studio esté solucionado, si no… lo tenemos complicado.
    No sé quién será el encargado de arreglar esto, supongo que los de VS, y esperemos que sea así, ya que el .NET 5.0 ha entrado en lo que llaman la fase “feature complete” (función completa) en la Preview 8 de hace una semana y ya solo nos quedan las release candidate en las que solo arreglan bugs, no añaden nuevas características.

    Habrá que reportarlo como BUG para ver si hacen algo y lo solucionan… porque si no lo solucionan, es que realmente no quieren que los desarrolladores de Visual Basic sigamos usándolo… y… optemos por cambiar a C#… en fin…

     

    Nota:
    Aunque al crear los proyectos de Windows Forms y WPF aparentemente sean para todas las plataformas, en realidad solo están soportadas en Windows.
    O al menos eso quiere decir (o es lo que yo entiendo que significa) esto en la configuración de la aplicación:

    <TargetFramework>net5.0-windows</TargetFramework>

     

    Espero que te haya servido para algo todo lo aquí comentado… ya sabes que esa es la idea 😉

    Nos vemos.
    Guillermo

  • Compilar y ejecutar (utilidad para .NET)

    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