Pues eso… algo tan simple como usar en .NET MAUI una DLL creada a partir de un proyecto del tipo class library, puede ser toda una odisea. Te lo explico para que te quede claro.
Como ya sabrás, puedes crear proyectos del tipo class library para añadirlos como referencia a otros proyectos que usen esa DLL o biblioteca de clases. Algo que es bastante común en cualquier aplicación para .NET ya sea .NET Framework como para .NET a secas incluido los proyectos para aplicaciones móviles con Xamarin.Forms. En estes último, lo que se suele hacer es usar una DLL compilada para .NET Standard. Hasta aquí todo bien.
La idea de usar una biblioteca de clases es para reutilizar el código en proyectos diferentes, es decir, creas la biblioteca de clases con cierta funcionalidad y esa misma biblioteca de clases la utilizas en proyectos diferentes. Al menos si esos tipos de proyectos son compatibles en el sentido de usar el mismo .NET.
Y como ahora estoy haciendo pruebas de Google Cloud Natural Language, pues pensé crear algún proyecto para .NET MAUI que usara esa API. Y como ya tenía el código de ciertas clases creado como proyecto DLL (Class Library) pensé agregar la referencia al proyecto de .NET MAUI y… ¡yaumate! (una expresión de mi zona que quiere decir algo así como… ¡tararí que te vi! o… ¡que te lo has creído!)
¡Y así fue! ¡Me lo creí! Pensaba que en .NET MAUI las cosas seguirían siendo como en el resto de .NET, pero no…
De hecho, hasta creé una class library usando la plantilla de MAUI, pero ni por esas… el proyecto de .NET MAUI nada más que daba errores de que no se podía tener referencia a esas clases definidas en la DLL (o class library).
La solución que tomé fue añadir directamente el código de esas clases en el mismo proyecto de .NET MAUI y así funcionó, pero no era eso lo que yo pretendía, ya que además del proyecto para .NET MAUI tenía otros proyectos: de tipo consola de Windows Forms para C# y Visual Basic y en todos ellos pretendía usar la misma DLL o biblioteca de clases.
Pero la solución buena ha sido creando una DLL (proyecto del tipo Class Library), crear un paquete de NuGet y usar ese paquete como referencia en lugar de una referencia al proyecto de tipo class library.
Decirte que esa referencia, al proyecto, sí que funciona en los proyectos de tipo consola o de tipo Windows Forms, tanto para VB como para C#, pero no si el proyecto es de .NET MAUI.
Te lo explico por si alguna vez te pasa esto… para que no te calientes la cabeza ni pierdas todo el tiempo que yo he perdido.
Y para muestra, el proyecto ElizaNET y el correspondiente Eliza MAUI (los enlaces van al repositorio de GitHub), que ambos usan una DLL compilada para .NET 7.0 y que funcionan a la perfección (salvo los bugs que se puedan producir en esa biblioteca de clases, que algunos pueden surgir).
Esos dos proyectos usan el código publicado en NuGet de Eliza gcnl Library que ahora va por la versión 1.0.2.
El código fuente de esa DLL (o paquete de NuGet) está en este enlace (dentro del repositorio ElizaNET).
Y esto es todo… espero que te sea de utilidad. Esa es la intención.
Pues eso… todo iba bien con las aplicaciones de .NET MAUI para iOS (después de muchos quebraderos de cabeza) y ahora, de buenas a primeras, empezó a pasar después de actualizar Visual Studio 2022 de la versión 17.3.5 a la 17.3.6.
Nota del 16-oct-22:
Solución a medias (que al menos me sirve para seguir probando las aplicaciones de .NET MAUI en iOS).
He usado el proyecto en otro equipo (un laptop/portátil) con Visual Studio 2022 Preview y ahí sí que ha funcionado todo. Así de simple. No es mi equipo habitual, y las copias que tengo no incluyen los ficheros de github, pero al menos me ha permitido seguir probando cosas.
Un consuelo como otro cualquiera. 😉
El error que me ha dado es este:
Error: CS1705 Assembly ‘Microsoft.Maui’ with identity ‘Microsoft.Maui, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’ uses ‘Microsoft.iOS, Version=16.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065’ which has a higher version than referenced assembly ‘Microsoft.iOS’ with identity ‘Microsoft.iOS, Version=15.4.300.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065’
He reportado el error, ya que lo que encontré no me solucionaba el problema.
Lo último que hice fue desinstalar totalmente el Visual Studio 2022 y después volver a instalarlo, antes hice un Rollback a la versión anterior, y probé con prácticamente todas las opciones de dotnet workload, pero sin ningún resultado favorable.
En el bug que reporté me decían que estaba duplicado y ahí he leído que aparte de desinstalar el Visual Studio, hay que desinstalar el SDK de .NET 6, esto último no lo he hecho pensando que se instalaba con el propio Visual Studio, lo mismo que el SDK de .NET 7 se instala con el Visual Studio 2022 Preview (que ya antes lo tuve que desinstalar para que las apps de .NET MAUI funcionaran sin darme error de que faltaban workloads.
Bueno, pues voy a ver si puedo desinstalar el .NET SDK aunque tenga que volver a instalar el Visual Studio al completo… 🙄
Ya te iré contando. 🤞🏻🙏🏻🤔
Pasos seguidos
Paso 1: Desinstalar el .NET SDK 6.0.305
Figura 1. Desinstalar el .NET SDK 6.0.305
Paso 2: Desinstalar el .NET SDK 6.0.402
Figura 2. Al desinstalar el .NET SDK 6.0.305 dice que nones
Como ves en la figura 2, al querer desinstalar el .NET SDK 6.0.402 me dice que no, que lo ha instalado el Visual Studio.
Después del paso 2, la cosa sigue igual.
Paso 3: Desinstalo los SDK de MAUI y .NET 6 desde el instalador de Visual Studio
Figura 3. Desinstalo desde el instalador de VS los SDK de MAUI y los de Android, iOS y normal
Ahora se supone que no podré crear nada… salvo la app de Windows. A ver qué pasa…🤞🏻
Estos son los errores que me da el Visual Studio al no tener los SDK (figura 4), ni la app de Windows funciona (normal, no hay ningún SDK válido).
Figura 4. Los errores de Visual Studio al no tener los SDK.
Ahora probaré a volver a instalarlos. Aunque antes voy a reiniciar el equipo.
Paso 4: Después de reiniciar el equipo, quito todo del instalador de Visual Studio
Y ahora iré añadiendo los workloads y demás…
Figura 5. Quito todo y ahora a indicar lo que se debe instalar
Paso 5: Selecciono los Workloads en el instalador de Visual Studio
Figura 6. Selecciono los Workloads en el instalador de Visual Studio
Y compruebo que los SDK estén (figura 7)
Figura 7. Los componentes individuales al configurar los workloads
A ver qué pasa después de instalar… 🤞🏻🤔
Conclusión de estos 6 pasos
¡No hay ná que rascar! todo sigue igual de mal (con la app para iOS). Las aplicaciones de Windows y Android van bien.
Ahora me toca quitar el SDK de iOS a ver qué pasa… Ya no sé si cruzar los dedos o levantar uno… 🤔🙄☝🏻 (pero no el central que no es plan, jajaja)
Paso 7: Quito el SDK de iOS
Con esto tampoco funcionará, pero a ver si lo puedo instalar usando dotnet workload.
Figura 8. Quito el SDK de iOS
Esto es lo que muestra dotnet --info antes de hacer nada.
Ahora en el proyecto no me muestra las opciones de probar ni con iOS ni con Android y el que tiene una advertencia en las dependencias es el net6.0-android. En fin… 🙄
Paso 9: Instalo nuevamente los workloads (y SDKs) para MAUI (que se había desmarcado)
Paso 10: Instalo nuevamente el .NET 6.0 SDK (v6.0.305)
Figura 9. Instalo nuevamente el .NET SDK 6.0.305
Aunque antes voy a probar usando el que tenía antes (con el .NET 6.0.402) por si el instalador de Visual Studio lo ha dejado bien (cosa que dudo, pero… ¡hay que tener fe! 🙏🏻)
Sigue con la misma cantinela.
Paso 11: Cambio en global.json la versión de .NET SDK a la 6.0.305 en vez de la 6.0.402
Intentaré ponerlo para que lo use la solución (del proyecto) con el fichero global.json y este contenido:
{
"sdk": {
"version": "6.0.305"
}
}
A ver qué pasa.
Lo suponía, ese SDK se incluía con el Visual Studio 17.2.9 y no incluye el .NET MAUI (que se incluyó con el Visual Studio 2022 17.3 😒
Por tanto, no se puede hacer nada ni con Windows siquiera… ¡Los milagros en Visual Studio no existen! 🤣
Paso 12: Vuelvo a poner en el global.json el .NET SDK 6.0.402
Y cuando abro el Visual Studio me sale esto:
Figura 10: Encima con cachondeo
Que tome una «survey» de mi experiencia con el desarrollo para iOS… si es que… 🙄
¡Hecho! Aunque, no hay mucho que decir… están más enfocados al emparejamiento con un Mac, que es lo que te permite distribuir las apps de iOS sin necesidad de tener el móvil junto a tu «computadora» para instalar la app.
Pero tampoco funciona… sigue con el mismo error.
Seguimos…
Paso 13: Vuelvo a probar con dotnet workload restore Trucos_MAUI.sln.
Pero nada… sigue igual.
Paso 14: En vista que el .NET SDK 6.0.305 no me vale, lo vuelvo a desinstalar
Y después de desinstalar este SDK que ya no me vale, no sé qué más hacer… 🤷🏻♂️
Nota del 13-oct-22 00.08: Como consuelo me ha quedado que al menos las apps de Xamarin para iOS funcionan desde Visual Studio 2022, ya que en Visual Studio 2019 no pueden firmar la app… cosas que pasan… Ver esto: Truco 3 de .NET MAUI.
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.
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.
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 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.
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 😉
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».
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.
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).
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… 😉
Pues eso… pero el título completo debería ser: Solución si actualizas a Windows 11 desde Windows Insider Program y no te muestra los iconos de la barra de tareas y/o al pulsar en un icono del escritorio o un ejecutable desde una carpeta te da error o al pulsar en un icono de una carpeta o al pulsar combinaciones de teclas Windows, después de tomarse su tiempo va apareciendo poco a poco.
El truco lo he sacado de uno de los muchos posts sobre incidencias con las actualizaciones de Windows, particularmente una de las respuestas de uno de ellos:
Los pasos que yo he seguido para poder poner en marcha el Windows 11 en mi laptop (portátil) el cual me decía (y sigue diciendo) que no es compatible para Windows 11, son estos: (están en inglés porque lo he puesto como respuesta a un feedback de Windows Insider Program que creé al pasarme eso que te he comentado al principio).
I used these «modifies steps» because I can’t show up the cmd window to type the full text to change the registry and reboot the PC
1: Use CTRL-ALT-DEL and choose to open Task Manager. 2: Choose “More details” at the bottom of Task Manager to expand Task Manager. 3: Go to “File” and choose “Run new task”. 4: Type in the “Open” field: reg delete HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\IrisService /f Then press the RETURN key. 5: Then restar the computer (You can use again CTRL-ALT-DEL and select Restart from the Power button on the right bottom side of the screen. After rebooting, everything should be back to normal.
Esta es la traducción de Google:
Usé estos «pasos de modificación» porque no puedo mostrar la ventana de cmd para escribir el texto completo para cambiar el registro y reiniciar la PC
1: Use CTRL-ALT-DEL y elija abrir el Administrador de tareas. 2: Elija «Más detalles» en la parte inferior del Administrador de tareas para expandir el Administrador de tareas. 3: Vaya a «Archivo» y elija «Ejecutar nueva tarea». 4: Escriba en el campo «Abrir»: reg delete HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\IrisService /f Luego presione la tecla RETURN. 5: Luego reinicie la computadora (puede usar nuevamente CTRL-ALT-DEL y seleccionar Reiniciar desde el botón de Encendido en la parte inferior derecha de la pantalla.
Después de reiniciar, todo debería volver a la normalidad.
En las siguientes capturas puedes ver cómo tenía el escritorio antes de actualizar de Windows 10 Pro a Windows 11 Pro OS Build: 22000.176.
Figura 1. El Windows 10 antes de reiniciar para instalar el Windows 11
Figura 2. El Windows 11 con los problemas de no mostrar los iconos del taskbar, etc.
Figura 3. Después de aplicar el truco explicado.
Si te fijas en las figuras 1 y 3, me indica que ese equipo no es compatible con Windows 11, pero después de haber cambiado al canal Beta de Windows Insider Program ya si pude instalarlo, creo recordar que hace unos meses no podía seleccionar esa opción, ni la de Dev tampoco, esta última es para instalar versiones menos estables, ya que la que se instala con la opción Beta Channel es la más parecida a la que saldrá el próximo día 5 de octubre.
Y esto es todo… espero que re pueda ser de utilidad.
Nos vemos. Guillermo
P.S. 03-sep-21 20:43: Hoy he recibido de la gente de Windows Insider Programa la respuesta a lo que ya indiqué, con los pasos oficiales, que son los que compartió el que hizo el comentario que mencioné y que está en este enlace: El workaround oficial sobre este error.
Pues eso… como he publicado hoy un post sobre la charla/entrevista que he tenido con Héctor de León para su canal de YouTube (hdeleon.net (youtube.com)), al ir a actualizar el «widget» con los enlaces de las entrevistas al guille (está abajo a la derecha en un navegador de escritorio o sabe DIOS dónde en un móvil, pero está junto al otro botón para los donativos PayPal), va y resulta que me los muestra en bloques (como los bloques reutilizables) y al principio hasta me he asustado al ver que había «cosas» raras donde solo tenía que haber un <li>, la cosa rara después me he dado cuenta de que eran los números de línea… después (no recuerdo qué hice o dónde le di) se pusieron bien y ya se mostraban los números de línea a la izquierda y el código a la derecha.
Y he titulado «el post» como nueva cagada, porque la anterior (aparte de otras) es que me han quitado la posibilidad de pasar de modo «diseño» a ver el código HTML, cosa que solía hacer antes cuando quería cambiar el HTML para poner algunas cosas que con el diseñador no te permite (o yo no sé cómo hacerlo). Así que… por lo que he optado, por ejemplo, en el post sobre la charla esta con Héctor, es utilizar un bloque HTML para poder incluir el frame con el video que él ha publicado (y que te recomiendo que veas).
TIP: Aunque esa posibilidad de pasar del diseñador al editor HTML no se muestra al pulsar en la ruedecita esa que hay arriba a la derecha (ajustes/settings), puedes acceder a ese código HTML pulsando las teclas: Ctrl + Shift + Alt + M.
Y ya está, tenía que decirlo, y lo he dicho 😉
Y no solo lo digo aquí, que podría decirlo en el soporte de WordPress, pero… ¿ande andará ese soporte? porque yo no lo he encontrado, salvo que sea metiéndome en algún blog comunitario, pero tampoco me queda claro y ya a estas alturas de la vida, pues uno está JARTO de dar tantas vueltas para algo tan sencillo como indicar un fallo o una nueva característica a un producto.
Pues eso… Si estás haciendo una aplicación con Xamarin.Forms para iOS (de Apple) y quieres probar el código en un emulador o un dispositivo conectado a tu equipo, debes tener en cuenta que si estás desarrollando con Visual Studio para Mac todo irá bien, pero si estás usando Visual Studio para Windows, simplemente no te funcionará… salvo que antes te funcionase… ahora te lo explico 😉
Aclaro esto último: Según me cuentan hay un problema con el provisioning (el que se indica en iOS Bundle Signing), es decir, autenticar tu cuenta de Apple Developer (*) con la aplicación, debido a que recientemente Apple ha realizado un cambio que provoca que se bloquee temporalmente las peticiones y se obtenga un error.
También según me cuentan: Es una issue con prioridad alta y están revisándolo.
Así que… esperemos que pronto esté solucionado.
Lo que comenté de salvo que antes te funcionase es porque (también según me cuentan): Si en el PC, previamente se ha utilizado Hot Restart con la cuenta, se tiene en caché lo necesario para evitar alguna petición y por ese motivo, te puede funcionar sin problemas.
Capturas de iOS Bundle Signing
Aquí te dejo un par de (o tres) capturas de la opción iOS Bundle Signing en las opciones del proyecto para iOS, tanto en Windows (que es donde da el error) como en un Mac (que no da error y funciona sin problemas).
Figura 1. La firma (autenticación) en Visual Studio para Mac funciona correctamente.
Figira 2. Fallo al autenticar con Visual Studio para Windows usando un dispositivo.
Figura 3. Fallo al autenticar con Visual Studio para Windows usando el emulador.
Y esto es todo, espero que te sea de utilidad.
Cuando esté solucionado intentaré poner una nota en este post de que así es… ¡espero no olvidarme! 😉
Nos vemos. Guillermo
(*) Para desarrollar (creo que incluso para probar) aplicaciones de Xamarin.Forms para iOS (Apple) debes tener creada una cuenta de Apple Developer, que a día de hoy cuesta 99€ al año. Esa cuenta se debe usar tanto en Windows como en Mac.
P.S. Título en inglés: Provisioning issues in iOS apps with Xamarin.Forms built with Visual Studio for Windows.
