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 Studio\2017\Community\MSBuild\15.0\Bin” 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($@"SOFTWARE\Microsoft\MSBuild\ToolsVersions\{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

Windows 10 & Wave Engine

Si estas usando Windows 10 y tienes problemas con el editor de Wave Engine seguramente estés teniendo un error del tipo: SharpDXException.

Seguramente se deba a que falta por añadir una funcionalidad que por defecto está desactivada en Windows 10.

Simplemente ve a Settings/System/AppFeatures y selecciona la opción “Manage optional features”

Manage optional settings

Debes asegurarte de que tienes el componente “Graphics Tools” en tu lista:

Graphics Tools

Si no es así, haz clic en “Add Feature” y añádela.

¡Gracias @VicFerGar por la ayuda!

Espero que sirva.

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. Continúa leyendo CodedUI Test & Jenkins

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:

Parametrized CodedUITest

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

 

TFS, Xamarin y MSTests

Hace un tiempo vimos un pequeño truco para poder ejecutar tests en las builds de TFS para proyectos Windows Phone.

Me ha sido necesario hacer lo mismo con proyectos con Xamarin Android y Xamarin iOS y aquí os pongo mi experiencia y cómo lo he resuelto. Continúa leyendo TFS, Xamarin y MSTests

TFS, Windows Phone y MSTests

¿Quieres que en las builds que tengas configuradas en TFS se ejecuten los test de tu aplicación Windows Phone?

Seguramente habéis probado a incluir un proyecto del tipo “Windows Phone Unit Test App” y os habéis puesto a crear nuestros tan amados tests. Pero a la hora de incluirlo en el repositorio de código, os habréis dado cuenta de que pasa algo raro: Los test no se ejecutan. (Si no te has dado cuenta, deja de leer esto y ve a comprobarlo)

La cosa es que ese proyecto de test lanza un emulador de WP y ejecuta los test y eso TFS no lo soporta todavía. Así que tienes dos opciones:

1) Dejar de hacer tests de tu aplicación WP.

2) Continuar leyendo.

Bien, si estás aquí, te cuento la solución en unos cuantos pasos:

1) Añade un proyecto de test típico de Visual Studio: Visual Studio Unit Test Project.

2) A este proyecto de test, añade una referencia del proyecto Windows Phone 8 que estés desarrollando.

3) Añade una copia local de los assemblies de Windows Phone que necesites, por ejemplo:

– System.Windows

– Microsoft.Phone

Los encontrarás en el directorio C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Tools\MDILXAPCompile\Framework

4) Copialos a un directorio local, que también tendrás que subir al TFS, llámalo por ejemplo /lib/ y ahora edita el XML del proyecto de test (el .csproj) y reemplaza:

<Reference Include="System.Windows" />
<Reference Include="Microsoft.Phone" />

por:

  <Reference Include="System.Windows, Version=2.0.6.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, processorArchitecture=MSIL">
  <HintPath>lib\System.Windows.dll</HintPath>
</Reference>
<Reference Include="Microsoft.Phone, Version=8.0.0.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e, processorArchitecture=MSIL">
  <HintPath>lib\Microsoft.Phone.dll</HintPath>
</Reference>

Además, para evitar los warnings cada vez que compiles añade este elemento al primer grupo de <PropertyGroup> del .csproj:

<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>

A partir de este momento, cuando incluyáis vuestro proyecto en vuestro TFS vuestros tests se ejecutarán como si lo hiciesen en el emulador, pero sin tener que lanzarlos.

Espero que pronto den solución a este “problema” y lo incluyan en la próxima versión.

Este post ha sido gracias a una respuesta en stackoverflow http://stackoverflow.com/a/13035195 que me ha salvado el día.

¿Se os ocurre otra forma de conseguir el mismo resultado?

Espero que sirva.

Juan María Laó Ramos.

[ebook] Testing Unitario con Microsoft Fakes

Hace un tiempo encontré un recurso que me pareció bastante interesante de compartir con la comunidad hispano-hablante.

Me lié la manta a la cabeza y fui traduciéndolo poco a poco. Y gracias a Jose Bonnin (@wasat) y a los Visual Studio ALM Technical Rangers aquí tenéis el resultado:

MicrosoftFakes

Post en el blog de los Visual Studio ALM Technical Rangers: http://blogs.msdn.com/b/willy-peter_schaub/archive/2013/08/22/191-habla-espa-241-ol-testing-unitario-con-microsoft-174-fakes.aspx

Espero que sirva.

Una experiencia ALM ++

En estos últimos tres meses he tenido la oportunidad de aplicar Scrum y TDD de manera estricta.

Ha sido una experiencia muy enriquecedora y la voy a compartir con todos.

En el proyecto hemos usado Team Foundation Service y Visual Studio 2012 como solución ALM con la plantilla por defecto de Scrum. Con esto solventamos varias cosas de un plumazo:

  • Gestión del Backlog
  • Definición de Sprints
  • Gestión de Tareas.
  • Gestión de Bugs.

La interacción con el cliente también la hacíamos a través de la web del proyecto.

Lo que más me llamó la atención fué lo fácil que es la gestión de bugs. Cuando el cliente encontraba un bug, lo abría y le ponía la prioridad, el scrum Master lo comunicaba en el daily scrum y nos organizábamos para ver quién lo corregía

ALM

  • Teníamos definidas varias Builds para cada parte del sistema que lanzaba una compilación y ejecución de los Test Unitarios que había para asegurar que no se había roto nada.
  • También había otra serie de Builds manuales necesarias para generar una versión para desplegar en los distintos entornos Desarrollo, Pre-producción y Producción.

La verdad que esto de no salir de Visual Studio para crear un sistema es una bendición. En su día integré Jenkis, Trac y Subversion en un proyecto en .NET, me maravillaba lo que se podia hacer con estas herramientas. La verdad es que me costó un tiempo montarlo y después mantenerlo.

Y en una conversación con el Scrum Master me soltó esto:

“Luego te llegan los empalmados que si Subversion, Jenkins, Jira, Trac, Bugcilla, que es gratis. Si estás desarrollando en .NET, el intentar integrar todo eso para que funcione con .NET es posible, pero es cuestión de tiempo y dinero”

Y en estos tres meses de trabajo, le habremos dedicado 40 horas a estos temas (daily scrums incluidos) y todo sin salir de Visual Studio.