Cómo encontrar la versión de MSBuild que está instalada

Recientemente me ha sido necesario averiguar cual es la última versión de MSBuild que está instalada en el sistema. Hacer la comprobación de que existe un archivo en el path por defecto del tipo “C:Program Files (x86)Microsoft Visual Studio2017CommunityMSBuild15.0Bin” no es buena idea. Ya que por ejemplo puede que el usuario no lo haya instalado en ese directorio,

En StackOverflow tenéis una solución bastante interesante.

Los pasos:

1. Instalar el paquete de Nuget Microsoft.Build.Framework.
2. Las versiones 4.0, 12.0 y 14.0 dejan una entrada en el registro con el path:
   • • Podemos consultarla

   Registry.LocalMachine.OpenSubKey($@"SOFTWAREMicrosoftMSBuildToolsVersions{msBuildVersion}")
   

3. Para la última versión, la 15.0 hay que hacer algo más ya que esta última versión no deja huella en el registro.
   • Es necesario añadir el paquete Nuget: Microsoft.VisualStudio.Setup.Configuration.Interop
   • Y con este código es posible buscar en dónde está:

 var query = new SetupConfiguration();

<pre><code>    var query2 = (ISetupConfiguration2)query;

    var e = query2.EnumAllInstances();

    var helper = (ISetupHelper)query;

    int fetched;

    var instances = new ISetupInstance[1];

    do
    {
        e.Next(1, instances, out fetched);
        if (fetched &amp;gt; 0)
        {
            var instance = instances[0];

            var instance2 = (ISetupInstance2)instance;

            var state = instance2.GetState();

            // Skip non-complete instance, I guess?
            // Skip non-local instance, I guess?
            // Skip unregistered products?
            if (state != InstanceState.Complete
                || (state &amp;amp; InstanceState.Local) != InstanceState.Local
                || (state &amp;amp; InstanceState.Registered) != InstanceState.Registered)
            {
                continue;
            }

            var msBuildComponent =
                instance2.GetPackages()
                    .FirstOrDefault(
                        p =&amp;gt;
                            p.GetId()
                                .Equals(&amp;quot;Microsoft.Component.MSBuild&amp;quot;,
                                    StringComparison.InvariantCultureIgnoreCase));

            if (msBuildComponent == null)
            {
                continue;
            }

            var instanceRootDirectory = instance2.GetInstallationPath();

            var msbuildPathInInstance = Path.Combine(instanceRootDirectory, &amp;quot;MSBuild&amp;quot;, msBuildVersion, &amp;quot;Bin&amp;quot;, &amp;quot;msbuild.exe&amp;quot;);

            if (File.Exists(msbuildPathInInstance))
            {
                return msbuildPathInInstance;
            }
        }
    } while (fetched &amp;gt; 0);
</code></pre>

Jugando con este código ya podemos ver de una forma más adecuada dónde están instaladas las versiones de MSBuild.

Espero que os sirva.

Post original en StackOverflow

 

XAML, UWP y Sqlite

La primera vez que creas un proyecto UWP con Sqlite y recibes el error:

Unable to load DLL ‘sqlite3.dll’: The specified module could not be found. (Exception from HRESULT: 0x8007007E)

El problema es que aún falta un componente por agregar a tu proyecto.

Los componentes necesarios son:

• SQLitePCL
  
• SQLite for Universal Windows Platform
  
• Visual C++ 2015 Runtime for Universal Windows Platform Apps
  

El segundo y tercer componente son extensiones que deben estar instalados y se añaden al Proyecto desde Add Reference/Universal Windows/Extensions:

Espero que os sirva para no volveros locos como me ha pasado a mi.

Juan María Laó Ramos

Modificar el valor de un struct con Reflection

He estado trabajando con nuestro amigo @jacano, conocido por todos como ReflectorMan, y nos ha sido necesario modificar por reflexión el valor de una estructura (struct).

De todas las formas que encontramos de hacerlo, vimos que la más sensata es:

object boxedObject = myStruct;

….

Info.SetValue(boxedObject, structValue);

…

myStruct = (MyStruct)boxedObject;

El truco está en que al hacer el casting a object, estamos haciendo un boxing de la estructura, es decir, lo estamos convirtiendo en objecto, y podemos pasarselo al método SetValue(). Ya que todos sabemos que las estructuras se pasan por valor.

Y justo después casteamos ese objeto al tipo de la estructura para hacer el unbox y quedarnos con el valor de la estructura.

Espero que os resulte útil.

CodedUI Test & Jenkins

He necesitado integrar la ejecución de tests de interfaz con CodedUI Test para una aplicación de WPF con Jenkins.

El problema es que para poder ejecutar los test de interfaz es necesario una sesión interactiva iniciada. Con esa sesión se ejecutarán los test de interfaz que necesitan interactuar con el ratón y teclado. Lamentablemente esta sesión está activa mientras tengas por ejemplo una conexión por escritorio remoto (RDC)  abierta, pero claro, no queremos tener que abrir una RDC para pasar los tests.

Pues ha sido duro pero lo he conseguido, y aquí os dejo los pasos que he hecho para hacerlo

Nota: El Jenkins que hemos usado NO se estaba ejecutando como servicio así que si tienes Jenkins corriendo como servicio no se si esto te puede ayudar.

Un detalle de la parametrización de CodedUITests con CSV

Hay un detalle que no nos cuentan en MSDN  Creating a Data-Driven Coded UI Test

Resulta que me he puesto a crear el primer test parametrizado y en mi csv tenía este contenido:

User,Passwd
1111,pass0000
7777776,4444

Cuando se ejecutaba el test, en la row del test paremetrizado que debería obtenerme el “pass0000”, me estaba obteniendo un string vacío:

Para que no ocurra esto, simplemente hay que modificar el archivo csv y añadirle comillas a los valores que queremos que nos devuelva:

User,Passwd
“1111”,”pass0000″
“7777776”,”4444″

Me ha traido loco durante dos horas, espero que a alguien más le sirva.

Juan María Laó Ramos

 

Algunas claves para ser más productivo

El enésimo post sobre el Singleton (UPDATE 1)

La cosa es que el Singleton hace dos cosas:

• Se asegura de que sólo haya una instancia del objeto.

• SomeStuff()

El problema de hacer dos cosas es que viola la S de los principios Solid: Single Responisability Principle. Y esto hace que no sea fácilmente testeable.

Cuando quiero hacer que sea testeable quito el Singleton y lo sustituyo por una factoría, una clase estática y una clase que hace la funcionalidad de SomeStuff.

Aquí tenéis un ejemplo simple:

public static class Singletons
 {
     private static Factoria fact = new Factoria();

<pre><code> public static void HazLoTuyo()
 {
     fact.GetUnicaInstancia().DoStuff();
 }
</code></pre>

}

public class Factoria
 {
     private Clase unicaInstancia;

<pre><code> public Factoria()
 {
     unicaInstancia = new Clase();
 }

 public Clase GetUnicaInstancia()
 {
     return this.unicaInstancia;
 }
</code></pre>

}

public class Clase
 {
     public Clase()
     {
     }

<pre><code> public void DoStuff() { }
</code></pre>

}

De esta manera puedo testear la clase Clase sin preocuparme de que sólo hay una instancia de ella en el sistema.

Es por esto que me asalta la duda, ¿no será el Singleton un antipatron?

¿Cómo lo veis vosotros?

[Update 1]

Gracias a los comentarios voy a ir actualizando el post con algunas conclusiones y dudas que se me plantean.

Resumiendo un poco los comentarios, cuando sólo queremos una instancia de nuestra clase Clase (definida más arriba) suele ser buena idea usar un inyector de dependencias y registrar nuestra clase para que el inyector nos devuelva siempre la misma instancia.

De esta manera “invertimos el control” de la instanciación de nuestra clase, y podemos testearla de manera aislada.

¿Pero que pasa si no queremos meter un inyector de dependencias por el motivo que sea?

Podríamos meter una clase parecida a esta:

 public class ClaseFachada
 {
     private static Clase clase = new Clase();

<pre><code> public static void DoStuff()
 {
     clase.DoStuff();
 }
</code></pre>

}

De esta manera podemos usarla en nuestro código de esta forma:

ClaseFachada.DoStuff();

Como si fuese un Singleton, pero evitando el típico Clase.Instance.DoStuff(). La cosa es que si estamos desarrollando una librería y queremos que nuestra librería se use así.

¿Os parece adecuado? ¿Cómo lo mejoraríais?

Usar la API de SkyDrive para Javascript en una página local

Hola a todos, hoy voy a hablaros sobre las API Live que tiene disponible Microsoft y que podemos usar desde nuestras aplicaciones c#, JavaScript, Objective-C y Java, pero además, también está disponible una versión Rest para todo lo que no entre en estos lenguajes.

Vamos a centrarnos en la API para SkyDrive y sobre cómo podemos configurarla para usarla en una web que estemos desarrollando en una máquina local.

El único requisito que necesitamos es definirnos una aplicación en el “Live Connect Developer Center“. Es necesario crearnos una nueva App en la sección “My Apps” para obtener un client Id que vamos a necesitar para poder usar la API.

Si accedemos a la sección “SDK Interactivo” podemos irnos al primer ejemplo de la API de Sky Drive del  SDK Interactivo  y ver el código. El código que vamos a ver es código JavaScript, ya que no hay otra forma de verlo de manera interactiva en la web, pero en la documentación sí podemos ver cómo usarla desde C#, Objective-C, Rest y Java.

WL.init({ client_id: clientId, redirect_uri: redirectUri });

WL.login({ "scope": "wl.skydrive" }).then(
    function(response) {
        openFromSkyDrive();
    },
    function(response) {
        log("Failed to authenticate.");
    }
);

function openFromSkyDrive() {
    WL.fileDialog({
        mode: 'open',
        select: 'single'
    }).then(
        function(response) {
            log("The following file is being downloaded:");
            log("");

<pre><code>        var files = response.data.files;
        for (var i = 0; i &amp;lt; files.length; i++) {
            var file = files[i];
            log(file.name);
            WL.download({ &amp;quot;path&amp;quot;: file.id });
        }
    },
    function(errorResponse) {
        log(&amp;quot;WL.fileDialog errorResponse = &amp;quot; + JSON.stringify(errorResponse));
    }
);
</code></pre>

}

function log(message) {
    var child = document.createTextNode(message);
    var parent = document.getElementById('JsOutputDiv') || document.body;
    parent.appendChild(child);
    parent.appendChild(document.createElement(&quot;br&quot;));
}

Si ejecutamos este código se nos abrirá un selector de archivos que lo que nos va a permitir es seleccionar un archivo que tengamos en nuestro directorio de SkyDrive, logarnos si no lo estamos ya, y descargarlo. Este es sólo uno de los ejemplos que podemos probar, hay un montón en los que podemos ver cómo usarla para acceder al contenido, cómo recorrer los directorios, etc.

Sin embargo, y es el problema que quiero resolver y el motivo de este post, si usamos la librería JavaScript en una página web que estamos desarrollando, necesitamos hacer un “truco” para poder verlo funcionar en local.

Si os fijáis bien, en la primera línea de código:

WL.init({ client_id: clientId, redirect_uri: redirectUri });

Vemos, que primero tenemos que inicializar “algo” para poder usarla. Para configurarlo adecuadamente necesitaremos el “client id” que comentaba al principio del post y una “redirect_uri“. Pues bien, esa uri es un dominio al que se van a redireccionar las peticiones de la API, que necesitamos configurar en el panel de Live Connect:

Esa url debe ser de un dominio público y accesible por la api. Sin embargo, como estamos en desarrollo, nuestra web no está todavía disponible ni la tenemos desplegada en un servidor.

¿Qué podemos hacer?

La solución es bien sencilla, tan sólo tenemos que modificar nuestro etchosts para que el dominio que configuremos en el panel de control de Live Connect sea nuestra propia máquina. De esta manera la API funcionará perfectamente y podremos hacer nuestras pruebas en local antes de publicar nuestra aplicación en un servidor. Por ejemplo podemos definir en nuestro etc/host el dominio:  midominiodeprueba.com 127.0.0.1

Y en la página de configuración de la aplicación pondremos:

A partir de este momento ya podemos usar la API sin tener que estar publicando en un servidor nuestra aplicación y haciendo pruebas en él.

Una vez que tengamos nuestra web lista para desplegar, sólo hay que modificar esos valores para que todo vaya como la seda :).

Juan María Laó Ramos

Primer camino para alcanzar el Nirvana del Garbage Colector

Para ponernos en contexto y verlo más claro debemos saber que lo que vamos a ver es realmente importante en el mundo de los videojuegos ya que en este mundo el consumo de memoria y de recursos es algo crucial y hay que optimizarlos al máximo. En este sentido el proceso de recolección de basura es algo importantísimo ya que consume recursos del sistema y si se ejecuta en mitad del juego se puede producir una bajada de rendimiento importante.

En este primer post de la serie vamos a ver una de las formas de evitarlo.

Este es el post original de Shawn Hargreaves:

En este post vimos cómo saber si el recolector de basura de nuestra Xbox está tardando mucho. Vimos que el tiempo que tarda el recolector de basura es el resultado del producto del número de veces que se recolecta por la latencia misma de la recolección.

Esto nos hace pensar en dos formas de mejorar el rendimiento del proceso de recolección de basura. Podemos reducir el número de recolecciones, o podemos reducir la latencia del proceso de recolección. Con que consigamos reducir uno de esos valores se notará una mejora bastante notable en el rendimiento total.

En este post vamos a ver el primer caso:

Elegir una frecuencia de recolección adecuada

La frecuencia con la que se produce la recolección de basura es directamente proporcional al número de veces que reservamos memoria. Si nunca reservamos memoria, el proceso nunca se lanzará.

Para reducir el número de recolecciones, debemos reservar memoria para aquello que vamos a necesitar mientras cargamos los niveles, y evitar reservas de memoria en el tiempo de juego, evitando así que el recolector de basura entre en acción en mitad del juego.

Hay varias formas para evitar la reserva de memoria:

No reserves memoria (jah!)

Es simple, no hagas news de tipos por referencia. Está bien cuando lo hacemos con tipos por valor como Matrix, Vector3, Color y demás.

Cada vez que queramos hacer un new de un tipo por referencia, debemos usar un pool de objetos para reusar sus referencias. Los ejemplos de Particle y Audio 3D de creators.xna.com usan esta técnica, y SwampThingTom escribió sobre un pool genérico y reusable.

No uses clases que reserven memoria por sí mismas.

Cuando añadimos datos a una colección como un List<T> o un Dictionary<K,V>, se reserva memoria cuando se quieren ampliar. Podemos evitarlo usando el constructor existente en el que se indica el tamaño específico de la colección. Usando este constructor hacemos que se reserve la memoria necesaria para toda la colección haciendo que esta no tenga que ampliar ni disminuir la memoria que necesita.

Ten cuidado cuando formatees cadenas. Es difícil manipular cadenas en .NET sin causar reservas de memoria.

Evita que el CLR reserve memoria.

El CLR reserva memoria cuando ocurre el boxing. ¡Evítalos como si de una plaga se tratase! El boxing puede ocurrir por muchas razones, algunas son obvias, otras no tanto, veamos cuándo ocurre el boxing.:

• Si asignamos un tipo por valor a una variable Object.
• Si guardamos tipos por valor en una colección no genérica.
• Si accedemos a tipos por valor a través de una interfaz.
• Si usamos un enumerado como clave de un diccionario, las operaciones internas del diccionario generan boxings. Podemos evitarlo usando claves enteras (de tipo int), y hacer casting a los valores de nuestro enumerado antes de añadirlas al diccionario.

No dejes que el compilador de C# reserve memoria.

Puedes ser realmente tricky usar delegados (especialmente los que están definidos “inline”) sin hacer que el compilador reserve memoria. Esto es todo un mundo por sí solo, pero en caso de duda evita el uso de delegados o eventos

Los yield hacen que el compilador reserve siempre memoria.

Los foreach pueden reservar memoria sin cuidado. Pero ojo, esto no significa que tengamos que evitarlos. Suele ser la forma más rápida de recorrer una colección.  Aprended las reglas para usarlos de manera adecuada

Todo lo que no reserve memoria está bien.

A los discípulos del camino de la frecuencia se les permite tener estructuras de datos complejos. Pueden reservar cientos de miles de objetos mientras su juego carga, llenar el heap con una malla de objetos referenciados entre si. Siempre que no reserven nada después de que termine de cargar, el recolector de basura nunca se ejecutará, así que no hay problema ninguno en mantener en memoria objetos complejos.

Resumen

Hemos visto una forma de hacer que el recolector de basura no se ejecute mientras se está jugando al juego: evitando hacer reservas de memoria durante el juego, en vez de eso las hacemos en el proceso de carga y se mantiene todo en memoria.

En el próximo post veremos la segunda opción: Elegir la latencia adecuada.

Juan María Laó Ramos.

Post original.

Aliasing en Texturas

Nueva entrega de la serie sobre técnicas de antialiasing,  esta vez en DesarrolloWeb.com.

Espero que os sirva