Archivo por días: 30 marzo, 2021

Solucionando problemas varios con Xamarin.Forms para UWP

Pues eso… a raíz de lo que te puse hace un rato (sobre GetExecutingAssembly) que al querer hacer la captura en el proyecto de prueba (Prueba Mobile) para UWP (Universal Windows Platform o Plataforma Universal de Windows), resulta que no me funcionaba… pero como la otra aplicación que estoy haciendo (Reservas Kayak Mobile) para kayakmaro.com si que iba la versión para UWP, pues hice ahí la captura.

La cuestión es que tenía 4 errores, uno de ellos decía algo así:
type universe cannot resolve assembly, concretamente señalaba a una de las DLL que utilizo en el proyecto que usan las versiones de Android, UWP e iOS (bueno, esta última no, ya que he desistido en crear proyectos para iOS porque ni usando un Mac de forma remota lo compila).

El error concreto es (sin indicar el nombre de la DLL ni resto de información):
Cannot resolve Assembly or Windows Metadata file ‘Type universe cannot resolve assembly:

El proyecto ese que te comento que vale para las distintas versiones de la aplciación es una DLL (biblioteca de clases de .NET Standard 2.0) de forma que se pueda usar en distintas plataformas.
Esa DLL la tienes que tener referenciada en cada proyecto (de cada plataforma) y así es como funciona esto con Xamarin.Forms.
En mi caso, la DLL de .NET Standard se llama Prueba Mobile y la aplicación para Android es: Prueba Mobile.Android, y sin necesidad de poner mucha imaginación sabrás que la de UWP se llama Prueba Mobile.UWP.

Ese proyecto (el de la DLL) tiene referencias a otros dos proyectos, también creados para .NET Standard 2.0, en estos dos casos, los he hecho con Visual Basic para utilizar (con algunos cambios en cierto código) el código que ya tenía hecho y que no era plan de volver a hacerlo de nuevo y en C#, que es el lenguaje que usan las aplicaciones de Xamarin.Forms.

Pues bien, el error ese de error type universe cannot resolve assembly me apuntaba a una de esas dos DLL que hace referencia la DLL principal (el nombre da lo mismo), y según parece, al no encontrar esa DLL generaba otros errores, concretamente que no podía copiar ciertos ficheros de la carpeta obj\x86\Debug porque no existían.
Y ahí se quedaba.

Los erores de que no podía copiar ficheros de la carpeta obj\x86\Debug eran:
Could not copy the file «obj\x86\Debug\MainPage.xbf» because it was not found.
Could not copy the file «obj\x86\Debug\App.xbf» because it was not found.
Could not copy the file «obj\x86\Debug\Prueba Mobile.UWP.xr.xml» because it was not found.

Así que… me pongo a buscar en internet y me encuentro con varios consejos (algunos copiados de otros previamente hallados, por lo que supongo que el que lo decía, ni lo había comprobado), pero esos consejos (o casi todos) hacían referencia a .NET Framework y «el target framework» o a hacer referencias a paquetes NuGet, pero no eran esos los casos… ya que dicha DLL ni está creada con .NET Framework ni está en un paquete de NuGet, aún así… lo intenté… pero sin resultados, al menos con lo de los paquetes NuGet, ya que lo del target framework, como que no… en fin…

Por probar, copié el proyecto para UWP del otro proyecto al de prueba (cambiando los espacios de nombres, etc.), pero tampoco.

Que si eliminar el directorio .vs, que si eliminar las carpetas obj y bin, pero nada de nada…

La solución

Al final decidí añadir una referencia en el proyecto para UWP (que en realidad no debería hacer falta) a la DLL que generaba ese error, y… ¡SOLUCIONADO!
¡MANDA COHONES!

Repasando los errores

Y para ser más concreto, he vuelto a poner todo como estaba antes de solucionarlo, con idea de poder hacer capturas y ponerte la descripción exacta de los errores.

En realidad lo que he tenido que hacer es quitar la referencia a la DLL y eliminar las carpetas obj y bin del proyecto para UWP.

Esta es la captura de los errores de Visual Studio (pincha en la imagen para agrandar):

Figura 1. Los errores en Visual Studio.

Y esta captura (figura 2) tiene el proyecto para UWP con la referencia (realmente no necesaria) a la DLL que no puede resolver, hecho esto… todo funciona bien.

Figura 2. Las propiedades del proyecto con la referencia a la DLL «fatídica».

Te he dicho antes que realmente no necesaria (añadir la referencia al proyecto UWP) porque en realidad ese proyecto no utiliza esa DLL, y si la utiliza es a través de la DLL Prueba Mobile, que como puedes ver en la figura 3 tiene su propia referencia a MKNDatos, ya que desde el proyecto Prueba Mobile sí que se utilizan las clases de MKNDatos.

Figura 3. Los proyectos referenciados en Prueba Mobile.

Lo que he buscado en la red (en Google)

Aquí tienes el enlace (unod e ellos) que he usado para hacer la búsqueda en Google:

https://www.google.es/search?q=type+universe+cannot+resolve+assembly

Aunque en la figura 1 no se ve, originalmente me dio el XamlCompiler error WMC106 e hice esta búsqueda:

XamlCompiler error WMC1006

Y esto es todo amigo. Espero que, como de costumbre, te sea de utilidad 😉

Nos vemos.
Guillermo

Mejorar el rendimiento al usar GetExecutingAssembly

Pues eso… ya te lo comenté hace unos meses, aunque estaba escondido en las novedades de gsNotasNET.Android v2.0.0.33, y era porque me daba error (sin avisar, para más señas) a la hora de usar la forma recomendada de usar Assembly.GetExecutingAssembly.

En esa ocasión me daba error la aplicación de Xamarin.Forms y sin saber porqué… Pero la he vuelto a probar y por ahora, al menos en el IDE de Visual Studio 2019 va bien.
De todas formas, ya sabes si usas lo que te voy a explicar aquí, y ves que la aplicación casca, ya sabes porqué es.

La documentación (en inglés) dice esto:

For performance reasons, you should call this method only when you do not know at design time what assembly is currently executing. The recommended way to retrieve an Assembly object that represents the current assembly is to use the Type.Assembly property of a type found in the assembly.

Que en el idioma actualizado de Cervantes viene a decir esto (según Google Translator):

Por motivos de rendimiento, debe llamar a este método solo cuando no sepa en tiempo de diseño qué ensamblado se está ejecutando actualmente. La forma recomendada de recuperar un objeto Ensamblado que representa el ensamblado actual es usar la propiedad Type.Assembly de un tipo que se encuentra en el ensamblado.

Aquí te voy a poner el código (tanto de Visual Basic como de C#) para usar esta forma recomendada de asignar un ensamblado (de la clase System.Reflection.Assembly).

Este código está en bibliotecas (proyectos del tipo Class Library) para usar con .NET Standard 2.0 (de esta forma los ensamblados se podrán usar tanto en .NET Core como en .NET Framework).

Ejemplo para C#

public static string VersionDLL()
{
    var ensamblado = typeof(AboutViewModel).Assembly;
    var fvi = FileVersionInfo.GetVersionInfo(ensamblado.Location);
    // FileDescription en realidad muestra (o eso parece) lo mismo de ProductName
    var s = $"{fvi.ProductName} v{fvi.ProductVersion} ({fvi.FileVersion})" + 
        $"\r\n{fvi.Comments}";

    return s;
}

Ejemplo para Visual Basic

Public Function VersionDLL() As String
    Dim ensamblado = GetType(DatosMostrar).Assembly
    Dim fvi = FileVersionInfo.GetVersionInfo(ensamblado.Location)
    ' FileDescription en realidad muestra (o eso parece) lo mismo de ProductName
    Dim s = $"{fvi.ProductName} v{fvi.ProductVersion} ({fvi.FileVersion})" &
        $"{vbCrLf}{fvi.Comments}"

    Return s
End Function

Ese código mostrará la versión del ensamblado, la versión del fichero y la descripción, aunque en realidad a la propiedad a la que tienes que acceder es a Comments, ya que FileDesciption muestra lo mismo que ProductName.

Y aquí tienes una captura para la aplicación de Android con los comentarios de las 3 bibliotecas que estoy usando, 2 de ellas escritas con Visual Basic y la tercera (la que le da funcionalidad visual a la aplicación está escrita en C#).

Figura 1. Captura en el emulador de Android.
Figura 1. Captura en el emulador de Android.

Y esta otra captura es de la aplicación en el emulador (local) de UWP (Universal Windows Platform) pero con la aplicación real. Aunque en modo depuración.

Figura 2. Captura en el (emulador) de UWP.
Figura 2. Captura en el (emulador) de UWP.

Espero que te sea de utilidad… Esa es siempre la idea…

Nos vemos.
Guillermo

P.S.
El puñetero Jetpack agrega código (de más) a las imágenes y cuando estas se muestran desde www.elguille.info, simplemente no se ven… pero… puedes pulsar en el sitio (en blanco) en el que está la imagen y te la mostrará…
Lo mismo quito el Jetpack, que, aparte del «bloque» Markdown y el poder publicar en twitter y mi sitio de facebook, no me sirve de mucho…