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… aquí te dejo el código de una clase (Frases) para analizar un texto usando la API de Google Cloud Natural Language y un par de proyectos para usar esa clase. Los proyectos son para una aplicación de consola y para dispositivos usando .NET MAUI. Todo el código está para C#.
No te voy a explicar mucho por aquí, salvo lo indicado en el siguiente párrafo, pero te dejo todo el código fuente (para C#) en este repositorio de GitHub. También incluyo algunas explicaciones y problemas que he tenido para usar la clase en el proyecto para .NET MAUI (no muchos, pero…)
Algunos trucos en el código de .NET MAUI
Un par de cosas que siempre suelo poner en los proyectos para .NET MAUI, porque no tienen la misma funcionalidad que con Xamarin.Forms, son:
Definir el tamaño de la ventana para Windows, ya que en .NET MAUI la ventana se muestra enorme y no recuerda el tamaño último. Esto lo hago en el constructor de la clase App.
Hacer que el control Frame se vea al completo (no se corte por la parte inferior). Esto lo consigo si en el StackLayout usado después del Frame se le deja un margin mínimo de 2.
Además, he añadido el código para simular un Expander ver figura 1). Este expander lo utilizo para mostrar u ocultar la lista de textos de prueba.
Otra cosa interesante es usar un objeto Task (usar otro proceso) cuando se pulsa en el botón de analizar, con idea que se muestre el texto mientras está analizando el texto y no se quede «congelada» la ventana.
Este es el código del evento Clicked del botón de analizar:
privateasyncvoid BtnAnalizar_Clicked(object sender, EventArgs e)
{
txtResultado.Text = "";
string tmp = txtTexto.Text;
if (string.IsNullOrEmpty(tmp))
{
MostrarAviso("Por favor indica el texto a analizar de al menos 3 caracteres", esError: true);
txtTexto.Focus();
return;
}
text = tmp;
HabilitarBotones(false);
awaitTask.Run(() =>
{
MostrarAviso("Analizando el texto...", esError: false);
frase = Frases.Add(text);
BtnMostrar2.Dispatcher.Dispatch(() =>
{
// Inicialmente mostrar todo sin tokens
BtnMostrar2_Clicked(null, null);
});
QuitarAviso();
});
HabilitarBotones(true);
En los métodos llamados desde Task.Run se tienen en cuenta el Dispatcher de los controles que se modifican, con idea de que no den problemas al hacerlo entre hilos diferentes.
Este es el código de los métodos QuitarAviso y MostrarAviso que modifican una etiqueta y un StackLayout.
Aquí tienes un par de capturas de la app para .NET MAUI en funcionamiento, en la figura 1 está funcionando en Windows (usando el expander), en la figura 2 antes de poner el expander y en la figura 3 en un móvil con Android (antes de poner el expander), en iPhone no me funciona (tampoco el resto de los proyectos que tenía, así que, no he podido hacer captura).
Figura 1. En Windows con el expanderFigura 2. En WindowsFigura 3. En Android
Te recomiendo que leas el post anterior para ver cómo crear un cliente de Google Cloud Natural Language y poder usarlo en estos proyectos, en ese post indico que el código es para Visual Basic, pero los pasos a seguir son los mismos para Visual Basic que para C#.
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.
