Archivo de la etiqueta: elguillemola

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.
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.
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.
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.
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.
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)
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

Sugerencias de palabras mientras escribes (Windows 11)

Pues eso… que en Windows 11 hay una opción de que te muestre sugerencias mientras escribes texto (ver captura 1).

 

Captura 1. Sugerencias mientras escribes.

 

Nota:
Como puedes ver en la captura 1, las sugerencias son en los idiomas que tengas instalados/configurados.

Para activarla o desactivarla entra en configuración y selecciona del panel izquierdo: Time & Language (captura 2).

 

Captura 2. En Time & language está Typing.

 

Pulsa en Typing y te mostrará las opciones disponibles (ver captura 3).

 

Captura 3. En Typing selecciona la primera opción para activar o desactivar.

 

La que activa o desactiva las sugerencias es: Show text suggestions when typing on the physical keyboard, evidentemente solo al usar el teclado físico (no el virtual).

La otra opción es Multilingual text suggestions que sirve para que te muestre las sugerencias en los idiomas que tengas instalado (y que soporten esta característica), por supuesto esa opción no tiene efecto si la anterior no está activada.

 

Y esto es todo por ahora… 😉

 

Nos vemos.
Guillermo

Indicar qué idioma usar en las aplicaciones en Windows 11

Pues eso… he instalado el Windows 11 en mi equipo «de trabajo» y como el Windows 10 que tenía era en español-España, así lo he tenido que dejar al instalar el Windows 11. Pero, aunque lo tenía en español, yo suelo usar el sistema operativo en inglés (costumbres), y seguramente le añadiría al Windows 10 el pack del idioma inglés (United States), pero claro… las cosas se me olvidan (y últimamente más, y no es tema de la edad, te lo puedo asegurar… no es por justificarme, ya que a la hora de escribir esto ya tengo los 64 cumplidos), total… que a mí me gustan usar los «shorcuts o teclas rápidas» en versión inglesa, es decir CTRL+S para guardar, CTRL+B para poner en negrita o el CTRL+A para seleccionar todo, por tanto, suelo tener las aplicaciones en inglés, y así tenía el OneNote para Windows 10 o el simple Notepad.

Nota:
En otras aplicaciones que el idioma es seleccionable, suelo usar el inglés también, pero en esas aplicaciones no les afecta el idioma del sistema (o casi).

Y ahora, al reinstalar el Windows 11, esas aplicaciones me salían en español, que no es el problema, pero sí lo es esos «atajos de teclas».

Después de varias vueltas, me di cuenta de que el idioma usado en las aplicaciones es el que se indique primero en la lista de idiomas, que está en la configuración: Time & language > Language & region (ver captura 1).

 

Captura 1. La configuración de Hora e idioma.

 

 

Y esto es todo… es por si me pasa de nuevo o por si te pasa 😉

 

Nos vemos.
Guillermo