Crear acceso directo a una máquina virtual (para no tener que abrirla desde el Hyper-V Manager)

Pues eso… que estoy usando algunas máquinas virtuales de Hyper-V para los canales de Windows Insider, una de ellas con la del canal Dev (más inestable) y otra con el canal Beta (algo más estable) y cada vez que enciendo el equipo (o lo reinicio tras una actualización) tengo que abrir el Hyper-V Manager para poder acceder a esas máquinas virtuales.

Pensando (algunas veces me da por pensar estas cosas) que lo más simple sería poder tener un acceso directo y abrir las máquinas sin tener que usar el administrador de Hyper-V, así que… buscando en la red me encontré que es fácil hacerlo… pero como suelo darle nombres (con espacios) a esas máquinas virtuales, en esos ejemplos no aclaraban cómo hacerlo, así que… me he decido a publicar esto para que quede constancia de cómo hacerlo (ya sabes, después de un tiempo puede que se me olvide y así podré encontrarlo al hacer una búsqueda en la red de redes 😉 )

Y de paso, te lo explico por si quieres hacerlo.

Primero lo primero

Lo primero a tener en cuenta es cómo crear ese acceso directo.

Para crear un acceso directo lo puedes hacer de dos formas.

La primera: Te posicionas en el directorio donde quieres crear ese acceso directo, por ejemplo, en el escritorio (que es la opción más rápida si quieres evitar tener que abrir esa carpeta con el acceso directo), pulsas en el botón secundario y de las opciones mostradas (ver captura 1 que es de Windows 11, pero en las versiones anteriores de Windows será algo parecido, pero con otro look) es elegir Nuevo > Acceso directo (New > Shortcut).

Captura 1. Crear un acceso directo en Windows 11.

A continuación, escribe el path del administrador de Hyper-V, que es el siguiente:
C:\Windows\System32\vmconnect.exe (ver captura 2).

Captura 2. Indicar el path de vmconnect.exe

Tip:
No lo busques en la carpeta de Archivo de Programas > Hyper-V, que ahí no está, ya que suele estar en C:\Windows\System32.

Pulsa en Siguiente (Next) y si quieres le cambias el nombre del nuevo acceso directo y finalmente pulsas en Finalizar (Fisnish) (ver captura 3).

Captura 3. Indicar el nombre del acceso directo

La segunda: Abre la ubicación de vmconnect.exe (que tal como te he indicado antes está en C:\Windows \System32, si en lugar de C usas otro nombre de unidad como arranque, indica ese nombre de unidad).

Busca el fichero vmconnect.exe y pulsa sobre la aplicación con en el botón secundario (el derecho para diestros, el izquierdo para zurdos) y selecciona crear acceso directo (como no podrás crearlo en la ubicación del programa, te preguntará si quieres crearlo en el escritorio).

El acceso directo estará en el escritorio.

Una vez creado el acceso directo a vmconnect.exe

Selecciona el acceso directo y pulsa con el botón secundario para elegir propiedades.

Después de la ubicación de vmconnect.exe indica el nombre del servidor de Hyper-V seguido del nombre de la máquina virtual.

En mi caso, sería GUILLE-JUL1421 «Windows 11Pro Dev» (ver captura 4).

Fíjate en las comillas dobles para el nombre de la máquina virtual, esto es así porque contiene espacios. Si el nombre de la máquina virtual no tiene espacios no es necesario ponerlo dentro de comillas dobles.

Captura 4. Usar comillas dobles si alguno de los parámetros tienen espacios

 

Dale permisos de administrador al acceso directo

Es necesario que le des acceso de administrador al acceso directo.

Para ello, en las propiedades del acceso directo, pulsa en el botón Avanzado (Advanced) y marca la casilla de Ejecutar como administrador (Run as administrator) (ver la captura 5), y acepta hasta cerrar la ventana de propiedades.

Captura 5. Indicar que el acceso directo se ejecute como administrador

Para saber con seguridad cómo se llama el servidor de Hyper-V y la máquina virtual, puedes verlo abriendo el administrador de Hyper-V (Hyper-V Manager) y así estar seguro (ver captura 6).

Captura 5. El administrador de Hyper-V

 

Nota:
En algunas ocasiones, al abrir los 2 accesos directos que suelo utilizar, en Windows 11, me los muestra en la barra de tareas como 2 iconos (ver captura 7) y otras veces como un solo icono, mostrando las dos opciones al pasar el ratón sobre él (ver captura 8).
En las versiones anteriores de Windows te los mostrará según tengas configurada la barra de tareas para mostrar los iconos relacionados con una misma aplicación.

Si abres las 2 máquinas virtuales desde el administrador de Hyper-V siempre te los mostrará como un solo icono.

Captura 7. En Windows 11 algunas veces (usando los accesos directos) los muestra como 2 iconos separados

 

Captura 8. La forma habitual de mostrar los iconos de un mismo tipo de aplicación en Windows 11

 

Y esto es todo… espero que te sea de utilidad… y si así ha sido (o no), no te olvides de invitarme a un «refresco virtual» 😉
(pulsando en el botón donar de PayPal).
Gracias.

Nos vemos.
Guillermo

Configurar una máquina virtual de Hyper-V para usar el Dev Channel de Windows Insider con Windows 11

Pues eso… que quería usa el Dev Channel de Windows Insider para tener la versión más reciente (aunque posiblemente más inestable) de Windows 11 y no me dejaba, solo me permitía los canales Beta y Release Preview. Y mire en la configuración de Hyper-V y… ¡ahí estaba la solución!

Y no es más que activar las opciones de Enable Trusted Platform Module (TPM) en la «pestaña» Security (ver la figura 1).

Figura 1. Configuración de una máquina virtual de Hyper-V para habilitar TPM.

No sé si será Es necesario marcar también la opción Encrypt state and virtual machine migration traffic, pero «for if las flais» también la he marcado (seleccionado), además de indicarle que utilice 2 procesadores virtuales (en la «pestaña» Processor).

Y con esos cambios ya me deja seleccionar (y que funcione) el canal «DEV» de Windows Insider Program.

Nota del 13-dic-21 01:57:
De todo lo dicho, además agrego que, con las pruebas hechas, si ponía 5120MB de RAM (5GB) no me lo daba por bueno… Con 6000MB (6GB) si lo da por bueno, ver la figura 2.
Y eso que dice que «al menos tiene 4GB de RAM», en fin…)

Figura 2. Con 6000MB (6GB) si lo da por bueno, con 5GB no me lo da por «compatible» para Windows 11.

Espero que te sea de utilidad… ¡esa es siempre la intención! 😉

Nos vemos.
Guillermo

Si instalas VS2022 y VS2019 deja de funcionar… (no carga todos los proyectos)

Pues eso… esto que te cuento ya lo publiqué en mi página de Facebook el pasado día 8 de noviembre (hoy es 23), pero «bicheando» en la WEB he visto que está expuesto este problema de forma más generalizada de lo que esperaba, y hasta gente de Microsoft han dicho que es bueno que esto se comparta para que haya menos gente que se encuentren con estos problemas (según parece esto lo han solucionado o lo van a solucionar en los instaladores de las nuevas versiones de Visual Studio 2022.

Como te comentaba en el post de Facebook, a mí el error que me dio fue: «The project file cannot be opened. Unable to locate the .NET SDK.«.

Esta es la entrada «ligada» al post en la página de Facebook de «elguille.info«:

 

 

Y aquí te lo dejo para que sepas cómo solucionarlo si te ocurre… Y si no te he ocurrido ¡chapó! 😉

Nos vemos.
Guillermo

Ahora entiendo mejor porqué ya no quieren seguir actualizando/avanzando Visual Basic

Pues eso… viendo las novedades de C# 10.0 me he topado con los detalles de la «novedad» Global using directives, dicho de esa forma parece algo «WOW!», y… es algo que siempre he querido que quitasen de forma predeterminada al crear un nuevo proyecto de Visual Basic para .NET: que haya importaciones implícitas de espacios de nombres al crear un nuevo proyecto.

Y eso es lo que es esa «nueva» característica de C# 10.0, crear definiciones «using» (ya que «Imports» es cosa de Visual Basic para .NET) de los espacios de nombres más habituales según el tipo de proyecto creado.

Que sí, que está muy bien, pero a mí nunca me ha gustado, de hecho, en la mayoría de los proyectos que creaba (sobre todo si era para compartirlo como parte de algún artículo), lo quitaba, con idea de así tener que escribir las importaciones de espacios de nombres en cada fichero (de código) de ese proyecto. Porque es la única forma de saber «a ciencia cierta» qué espacios de nombres se estaban usando en ese fichero de código.

Para que nos entendamos, a diferencia de C#, en Visual Basic el espacio de nombres System.Text nunca se importa de forma predeterminada, algo que sí ocurre en los proyectos de C#; por tanto, si quiero crear un nuevo objeto del tipo StringBuilder, o bien lo creo usando el nombre «completo» de la clase StringBuilder: System.Text.StringBuilder o bien declaro la importación del espacio de nombres System.Text y ya el compilador sabrá que StringBuilder está accesible (al revisar las clases contenidas en cada uno de los espacios de nombres que estén incluidos en las importaciones).

¡Eh! que no es una crítica, que me parece muy bien, y si ahora los del TEAM de C# lo están añadiendo como algo «predeterminado» será porque tampoco será tan malo, lo único que digo es que sigue siendo lo mismo que teníamos los «desarrollado-res» de Visual Basic desde hace ya casi 20 años… ¡NOVEDAD! WOW! 😉

Total, a lo que iba, que ya no hace falta seguir dando nuevas características a Visual Basic, porque al final C# será como era Visual Basic hace 20 años… eso sí, con (entre otras cosas) acabando la línea con un punto y coma.

Pero preferiría que Visual Basic evolucionara con las «nuevas características» realmente nuevas, para que a los que no nos gusta usar punto y coma para indicar que una instrucción ha finalizado o poner cosas entre llaves, etc., etc., y dejar de ver cómo C# evoluciona para hacer cosas que desde «siempre» ha hecho Visual Basic y, casi seguro, que era criticado por eso… Y si no me crees, échale un vistazo a las declaraciones sin tipos de variables (que, siempre al estilo de C#) en C# también lo añadieron en su día como novedad novedosa…

Nos vemos.
Guillermo

Un cuento de años de plata…

Érase una vez hace 25 años… empezó todo, sí, en noviembre del año 1996 es cuando empezó todo lo relacionado con elGuille en la WEB, es decir, todo esto de compartir código (y hasta conocimiento sobre el código compartido), crear tutoriales, explicarte trucos (que, según me decían, seguramente nadie te explicaba), acoger código que otros colegas también querían compartir, hacer amigos virtuales que después (no todos) llegaban a ser físicos y dejar la virtualización amiguera, dar charlas y talleres allende los mares, (incluso en mi tierra, sin alleandar los mares o cruzar el charco); y en realidad todo empezó por «probar» esto de los interneses y esas cosas… y ahora… pues… más viejo (empecé con… a ver: 1996-1957 = 39 años, los que ahora cuento son 64 añitos de nada, y con caja de dientes nueva (o recién puesta), todos míos, pero ninguno natural… míos porque al final los pagos yo… pero son pre-fabricados y anclados con tornillos… a ver si me acostumbro, jajajaja.

Pues eso… ( ¿creías que este post del blog no iba a tener el acostumbrado «pues eso…», jum! qué poco me conoces! 😉 ) aquí estoy escribiendo esto en el mes de noviembre, que la verdad no recuerdo bien en qué día exacto empecé, pero… como mi buen amigo Daniel Seara dice que es el día 20 de noviembre, pues… ¡será el día 20 de noviembre!

Esta vez no te pongo fotos de cómo era el sitio antes (sitio: elguille.info, blog: elguillemola.com), aunque ni era un sitio… si no, una «carpeta» en el «sitio» de mi amigo Manolo Franco, que después generó en un sub-dominio para (allá por el año 2005) ser definitivamente el sitio de elGuille: www.elguille.info.

Y ya está, solo para que no se olvide que hace ya una eternidad empecé a hacer mis pequeños escarceos en la red de redes para compartir conocimiento de programación en ese lenguaje que ya ni los de Microsoft quieren tener en cuenta: Visual Basic, pero del que ahora llaman (o llamamos) clásico, ya que el Visual Basic más actual (el de .NET) llegó sobre el año 2002, que es cuando empecé a cruzar el charco: concretamente en mayo de 2002 en la universidad de Colima, México, como ponente internacional en su VI Simposium de la facultad de telemática (espero no haberme olvidado de que era ese el número ni la facultad, ya que Colima sí que era, y que Colima está en México también, y que en ese mes me di un baño en el Océano Pacífico). Y a partir de entonces, hasta el año 2012 (con la gira por Perú), saltando el charco prácticamente todos los años, con el parón del año 2009 (ese año decidí estar todo el año en mi tierra nerjeña).

Bueno… pues… eso… 😉 espero que nos sigamos viendo unos cuantos años más, pero por aquí, por el blog que más mola: elGuilleMola.com.

Nos vemos.
Guillermo

Solución si en Visual Studio 2022 para Windows no te muestra el dispositivo físico en un proyecto para iOS de Xamarin.Forms

Pues eso… que empecé un proyecto de Xamarin Forms en Visual Studio 2022 con los proyectos para Android y Windows (UWP) pero no añadí el de iOS y después me planteé añadirlo porque, aunque yo no lo uso (no me funcionan en mi iPhone 7 Plus) mi hijo David sí le funcionan en su iPhone y en el iPad (David es de los que gustan usar las cosas de Apple, de hecho, está certificado como técnico en todo lo referente a Apple), y me encontré que ahora no me mostraba el «dispositivo» local en la lista de dispositivos, solo los habituales para usar con un Mac en línea.

Ver las capturas 1 y 2 para que así entiendas mejor a lo que me refiero.
En la captura 1 están las opciones que suelen mostrarse si todo está bien, y en la captura 2 se echa en falta el dispositivo físico.

Captura 1. El dispositivo físico aparece en la lista.

Captura 2. El dispositivo físico no aparece en la lista.

Nota:
Además de lo que te cuento aquí, para que se muestren los dispositivos físicos debes tener instalado en tu Windows el iTunes de Apple.

Aparte de lo comentado en la nota anterior, otra cosa que debes tener en tu proyecto para iOS es que haya una referencia a Xamarin.Forms (se me olvidó añadirla y casi me vuelvo loco buscando cómo solucionarlo) y ya, de esas cosas que te dan pro probar… probé a verificar las dependencias del proyecto y eché en falta la referencia a Xamarin.Forms, y fue añadirla y… ¡voilà! ahí está el dispositivo disponible, otra cosa es que funcione la aplicación, pero al menos está 😉

En las capturas 3 y 4 puedes ver las referencias del proyecto para iOS.
En la captura 3 no estaba incluido Xamarin.Forms y por eso no se mostraba el dispositivo físico.
En la captura 4 ya está esa referencia y ahora sí que muestra en la lista de dispositivos (si está conectado al USB del equipo, todo hay que aclararlo) el iPhone 7 plus que es el que yo heredé de mi hijo David 😉

Captura 3. Aquí falta la referencia a Xamarin.Forms (y no se muestra el dispositivo físico)

Captura 4. Con la referencia a Xamarin.Forms sí muestra los dispositivos físicos.

Y esto es todo… ya sabes… espero que te sea de utilidad (y espero que a mí me vuelva a serlo cuando me pase de nuevo… jejejeje, que conociéndome, seguro que me vuelve a pasar).

Nos vemos.
Guillermo

Edición ‘multi-caret selection’ en Visual Studio, pensaba que era un bug

Pues eso… yo pensaba que era un BUG de Visual Studio 2022 y me dicen que es «by design».

El tema era que al seleccionar con ALT+SHIFT (para seleccionar un bloque de código en las posiciones que quieras) se quedaban varios cursores activos y al escribir se escribía en todas las posiciones en las que estaba el cursor. Y dicen que eso no es un BUG (sí lo es en la forma que ha ocurrido, ya que en Visual Studio 2019 no ocurre de esa forma), y el enlace que me han dado es el siguiente: Multi-caret selection.

Este es el enlace al bug que les mandé: BUG VS2022: Selecting with ALT+SHIFT, releasing the selection, the blue and red cursor remains and if you type the text typed is set in several places.

Así que, si dicen que es «by-design», pues… lo será 😉

Nos vemos.
Guillermo

Solución al error en .NET MAUI: Error MSB4018 The «XamlCTask» task failed unexpectedly.

Pues eso… todo el rollo que te conté ayer… al final tenía una fácil solución o su solución era fácil. Y es no usar el idioma de Cervantes.

Ya te conté todo el rollo con las aplicaciones usando las plantillas de .NET MAUI con Visual Studio 2022, que al final no compilaban por el dichoso error: Error MSB4018 The «XamlCTask» task failed unexpectedly. Y no era por otra cosa que por usar caracteres acentuados (con tilde) en el diseñador de XAML.

En la otra aplicación que me funcionaba, seguramente «de casualidad» no tenía ese tipo de caracteres, y me estaba volviendo loco. Porque ya no sabía qué hacer.

Y hoy, leyendo otro «feedback» al querer postear el error, era porque alguien quería usar un «dibujito» en el XAML y resulta que le daba error… y la solución era usar el código que corresponde a ese dibujo para así mostrarlo.

Yo lo he solucionado poniendo en el código el texto a mostrar.

Y lo que quería hacer era un ejemplo en el que se escribe un número en una caja de texto, se pulsa en un botón y se muestra el número escrito. Este ejemplo tan «simplón» es solo para demostrar a esta gente de Visual Studio / .NET MAUI que el control Entry falla y que solo admite el texto que se asigne, ya sea en tiempo de diseño o en tiempo de ejecución, pero que si escribes algo, ese valor no se tiene en cuenta, solo se usa el inicialmente asignado.

En la captura 1 puedes ver el proyecto en ejecución en el proyecto para Windows (UWP), y ahí te muestro que a pesar de haber escrito otro número distinto al asignado inicialmente (5) en la etiqueta no muestra el que se haya escrito.

Captura 1. La aplicación para .NET MAUI en funcionamiento.

Pues ya lo sabes (y espero yo saberlo también) 😉

Nos vemos.
Guillermo

Solucionando problemas con los proyectos de .NET MAUI en Visual Studio 2022 (o casi)

Pues eso… seguimos con los «problemitas» de Visual Studio 2022 y .NET MAUI. Después del fallo que te comenté anoche, me puso en la labor de crear un nuevo proyecto de .NET MAUI en Visual Studio 2022, con idea de comentar otro de los fallos con los que me encontré y es que en los controles Entry no se cambia el valor que hayas asignado (en diseño o por código).

Creé un nuevo proyecto de .NET MAUI, pero… nada de nada… el error que me mostraba (después de varios «cleanings» y «rebuilds» era que: XamlCTask «nosequénosecuántos» y ahí se quedaba.

Esto ya me pasó otra vez, lo solucioné (pero no recordaba como lo hice), por eso estoy escribiendo esto… por si lo soluciono lo tendré a mano 😉

Lo que ahora estoy haciendo (o el Windows 11 está haciendo) es esto:

Paso 1: Ejecutar maui-check.

En la línea de comandos (yo he abierto el terminal de Windows 11) escribe:
maui-check.

Esto comprueba si el «.NET MAUI» está correctamente instalado.

Nota:
Si esa utilidad no la tienes instalada… pues… tendrás que instalarlo, tal como te dije hace unos meses.

dotnet tool install -g redth.net.maui.check

Paso 2: Descargar e instalar todo lo que necesita .NET MAUI.

Escribe en la línea de comandos o la terminal de Windows 11:
dotnet workload install maui

Esto descargará e instalará lo que necesite tu equipo.

Ver la captura 1 con los dos comandos comentados.

Captura 1. El terminal de Windows 11 con los dos comandos.

Aunque esto no soluciona el error ese de Error MSB4018 The «XamlCTask» task failed unexpectedly. 🙁

Paso 3: Crear un nuevo proyecto.

Yo lo he creado desde la línea de comandos:
dotnet new maui -n MauiApp3
MauiApp3 es el nombre del proyecto que le he dado.

Pero también lo puedes crear desde el propio Visual Studio 2022.

En nuevo proyecto escribe MAUI en la búsqueda y pulsa INTRO y te mostrará los proyectos de .NET MAUI. Selecciona el primero tal como te muestro en la captura 2.

Captura 2. Nuevo proyecto de .NET MAUI.

Paso 4: Editar el proyecto en Visual Studio 2022 e indicar que admita aplicaciones de Windows.

Lo abro con Visual Studio 2022, (o lo creo, tal como te he indicado en el paso anterior), edito el fichero del proyecto (en el explorador de soluciones pulsa con el botón secundario en el proyecto y selecciona Edit Project File) y quito el comentario en la línea:

<TargetFrameworks Condition="$([MSBuild]::IsOSPlatform('windows')) and '$(MSBuildRuntimeType)' == 'Full'">$(TargetFrameworks);net6.0-windows10.0.19041</TargetFrameworks>

En el valor TargetFrameworks que está justo encima de esa línea con los «frameworks» incluidos en el proyecto: net6.0-ios;net6.0-android;net6.0-maccatalyst.

Si ahora ejecutas el proyecto te dará error, ya que el «framework» que usará será el primero de la lista: net6.0-ios. Aunque arriba esté indicado que será en Windows Machine.

Para solucionarlo, debes cambiar el target framework indicado en la aplicación de Windows y seleccionar el de Windows (ver la captura 3):

Captura 3. Indicar el framework para las aplicaciones de Windows.

Abajo, en la lista de errores más o menos te da pistas.

Y si después de eso (y tienes suerte) al pulsar F5 debería mostrarte la aplicación de ejemplo (ver la captura 4).

Captura 4, la aplicación de ejemplo en funcionamiento.

Nota interna pal Guille:
El proyecto que funciona (sin añadir código propio) es: MauiApp2 y MauiApp3 que están en «C / source / repos».

Una cosa a tener en cuenta:

Si pruebas con Android (emulador o dispositivo), y supongo que para iOS también, el framework se asignará correctamente, pero si vuelves a querer usar la aplicación en Windows, tendrás que volver a indicar el net6.0-windows10.0.19041.

Ahora no se te ocurra añadir tu propio código… jajaja porque es cuando empieza el espectáculo del error ese que te dije antes en el paso 2: Error MSB4018 The «XamlCTask» task failed unexpectedly.

A ver si consigo solucionarlo, porque ni haciendo todo lo anterior me ha funcionado.

Porque funcionar (aunque regulín-regulán) me ha funcionado, pero ya no recuerdo qué hice. A ver si doy con lo que fue… y te voy contando, porque ya son cerca de las 4 de la tarde del nuevo horario y hay hambre 😉

*** Seguimos

A ver… creo que era lo que comentaban en este «reporte de error»: VS 2022 MAUI project templates missing.

Ejecutando este código: dotnet new -i Microsoft.Maui.Templates indica que está todo instalado (otra cosa es que añadas una nueva página al proyecto, en ese caso, como es Xamarin.Forms te dará errores por todos lados, pero básicamente es cambiar las definiciones de los «usings» y cambiar los xmlns del diseñador).

En mi caso, al ejecutar ese código (ver la captura 5) dice que está todo instalado (y que ya lo estaba).

Captura 5. Instalar los templates de .NET MAUI.

*** Seguimos (2)…

Yo qué sé… tengo un proyecto que funciona (mal, pero funciona con mi propio código), pero no consigo que los nuevos proyectos tengan el código que yo quiera (que de eso se trata, ¿no?).

Bueno, ahora sí, si lo soluciono, y sé/recuerdo cómo lo he solucionado, lo pondré aquí o en un post nuevo…

Solo me queda añadir una nueva página y ahí escribir el nuevo código…

Actualizado el 1 de noviembre de 2021.

Pues resulta que he conseguido crear un nuevo proyecto desde el propio Visual Studio 2022, añadirle código propio y hacer que funcione, y de paso comprobar que eso de los controles Entry falla.

Pero solo he tenido 3 oportunidades, desde la cuarta, ya no funciona… vuelve a salir el error de: The «XamlCTask» task failed unexpectedly.

Y ya… pues casi que lo dejo, hasta ver si es casualidad o es que se puede hacer algo para solucionar ese «dichoso» error.

Lo mandaré a esta gente a ver qué dicen… seguro que a ellos nunca les pasa 😉

¡¡¡Resulta que todo el problema eran las «tildes»!!!

Pues eso… he quitado una tilde que tenía en «número» y ahora funciona bien… jajajaja, como se suele decir: ¡pa mearse y no echar gota!

Es decir, el error de The «XamlCTask» task failed unexpectedly es porque hay caracteres «no normales».

Nos vemos.
Guillermo

.NET MAUI aún está muy verde (comparado con Xamarin.Forms)

Pues eso… por fin he logrado hacer algo medianamente útil con .NET MAUI y Visual Studio 2022 (acceso a datos, para ser más concreto) y… pues que en la aplicación de Windows (UWP) funciona bien, pero en la de Android ni de coña… Y ya con la de iOS ni te digo… es que ni siquiera compila… en fin…

La de Android se inicia, pero cuando digo de acceder a una base de datos, da error.

Seguramente será por el «idioma» (codificación). Ya que en las aplicaciones de Xamarin.Forms para que pueda acceder a las bases de datos de SQL Server le tengo que decir (a iOS también) que use la codificación WEST y entonces si funciona (ver la captura 1), pero no tengo ni repajolera idea de cómo hacerlo en .NET MAUI. 🙁

Captura 1. La opción en Xamarin.Forms para indicar que use la codificación oeste (west)

De todas formas, aunque funcione en Windows (me vale para las pruebas), hay cosas tan simples como que un Entry (el típico TextBox de .NET Framework, o casi) no permita que se cambie el contenido… Bueno, permitir, lo permite, pero como si le echaras un vaso de agua al mar para que aumente de nivel… Es decir, que no vale pa ná

En fin… y el día 8 de noviembre quieren lanzar el Visual Studio 2022… ¡que lo lancen! pero bien lejos… porque falla más que una escopetilla de plomos…

Eso sí, uno le dice a esta gente que fallos va encontrando, pero… ¡a ellos no les falla!… jajajaja me rio yo solo… por no llorar…

De hecho, con un bug «tonto» de seleccionar código con las teclas ALT+SHIFT (suelo hacerlo bastante cuando quiero copiar el código para colorearlo y publicarlo en este blog, por ejemplo).

Pues no hay forma de que esta gente sigan los mismos pasos que ya les he indicado varias veces, ellos lo hacen a su manera, y de esa forma no falla… pero no es lo mismo. Ya que, si yo quiero seleccionar algo que está indentado, en Visual Studio 2022 falla, sin embargo, en Visual Studio 2019 va bien.

Si tienes curiosidad, puede ver el «feedback» que yo lo titulé (en inglés para que no se pierdan mucho): BUG: Selecting block of text with SHIFT+ALT (+ Down, Left keys) moves the selection start down (not always).

Y algunos más… que, hasta pueden resultar graciosos, como el que al seleccionar el texto de esta forma se quedan varios cursores y si escribes algo se pone ese texto en todos los cursores que haya (uno por cada línea seleccionada).

Este es el enlace (y el título): BUG VS2022: Selecting with ALT+SHIFT, releasing the selection, the blue and red cursor remains and if you type the text typed is set in several places.

Bueno… no te canso más… aunque, si vives por estos lares… esta noche podrás dormir una hora más… que nos cambian el horario de verano al de invierno y… a las 3 de la madrugada serán las 2… 😉

Buenas noches.

Nos vemos.
Guillermo