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.

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

 

[Evento CartujaDotNet] ALMdeando

El próximo Miércoles 11 de Marzo de 2015, desde Cartuja .NET organizamos una sesión de charlas en las que veremos diferentes tecnologías para mantener y mejorar los procesos de desarrollo de software.

Dragon¿Te apuntas?

Fecha

El evento tendrá lugar el próximo Miércoles, 11 de Marzo de 19:00h a 21:00h. Las sesiones tendrán una duración de entre 30 minutos y 45 minutos con descanso intermedio de 5 minutos.

Lugar

Tendrá lugar en el Cloud Pointing de Sevilla situado en el Parque Empresarial Nuevo Torneo. Tenéis la información exacta del lugar a continuación:

c\ Biología, 12, Edificio Vilamar 2, 3ª Planta
Parque Empresarial Nuevo Torneo
41015 Sevilla

Agenda y Ponentes

Utilizando Integración continua con Apps Xamarin (Javier Suárez) (45 minutos)

En esta sesión Javier Suárez nos hablará de integración continua con Apps Xamarin. La integración continua es fundamental en el desarrollo de software, independientemente de la plataforma. Detectar problemas tan pronto como sea posible es una gran victoria, sobre todo en el mundo móvil. Veremos cómo ejecutar pruebas como parte del proceso de Build, que cubren las pruebas unitarias, etc.

Continuous Delivery con Release Management (Ibon Landa) (45 minutos)

En esta sesión veremos qué papel juega Release Management en el ciclo de vida de la aplicaciones y como lo podemos utilizar para implementar de principio a fin un pipeline de release para nuestras aplicaciones.

Después de una introducción a los conceptos más básicos de Continuous Delivery intentaremos ver de la forma más práctica posible la funcionalidad que aporta Release Management.

– Making better tests (Juan María Laó Ramos) (30 minutos)
En esta sesión Juanma nos contrará algunos trucos y buenas prácticas que ha aprendido arrastrándose por los barrizales de la programación, más que nada para evitar tener que poner muchas lavadoras después de llegar a casa y tener más tiempo para los suyos.

Más información

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?

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

Windows Azure: Release de Windows Azure SDK 2.2 (y sus chuladas)

Ya está publicada la nueva release de Windows Azure SDK 2.2. En esta release se han incluido un gran número de características:

  • Soporte para Visual Studio 2013.
  • Se ha integrado el Sign-In de Azure en Visual Studio.
  • Debugging remoto de servicios cloud con Visual Studio.
  • Soporte de administración de Firewalls en Visual Studio para bases de datos SQL.
  • Imágenes de máquinas virtuales con Visual Studio 2013 RTM para suscriptores MSDN
  • Windows Azure Managemente Libraries for .NET
  • Se han actualizado los Windows Azure PowerShell Cmdlets y ScriptCenter Continúa leyendo Windows Azure: Release de Windows Azure SDK 2.2 (y sus chuladas)

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.

StyleCop, TFS y Nuget

StyleCop es una herramienta que analiza nuestro código para ver si se cumplen un conjunto de reglas y estilos de codificación.

Por resumir un poco, el equipo que lleva el proyecto de StyleCop ha identificado un estilo y conjunto de reglas para la programación en C#. En esas reglas se define, por ejemplo, que todo método debe tener una sección de documentación, toda variable de clase debe estar documentada, etc … Si queréis ver cuales son esas reglas por defecto no dejéis de pasaros por la sección de la documentación dedicada a ello. No voy a entrar en la discusión de si esas secciones son necesarias o no para documentar el código ;). El objetivo que se busca con este proyecto es que todo el código esté escrito de manera homogénea, evitando de un plumazo las discusiones entre los miembros del equipo del tipo: “Has vuelto a poner el { en la misma línea del if …”

StyleCop en NuGet

Para integrarlo en nuestros proyectos, simplemente con NuGet, buscamos StyleCop:

StyleCop En Nuget

Una vez que lo instalemos los paquetes StyleCop y StyleCop.MSBuild en nuestro proyecto, si queremos que los errores que nos marca StyleCop sean errores de compilación en lugar de warnings tan solo tenemos que editar el .csproj y añadir la línea:

<StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>

En la sección que queramos que esto ocurra, por ejemplo, si queremos que esto sólo salte cuando compilemos en debug, buscaremos la sección de configuración para ello, y la añadiremos al property group:

&lt;PropertyGroup&gt;
    &lt;Configuration Condition=&quot; '$(Configuration)' == '' &quot;&gt;Debug&lt;/Configuration&gt;
    &lt;Platform Condition=&quot; '$(Platform)' == '' &quot;&gt;AnyCPU&lt;/Platform&gt;
    &lt;ProjectGuid&gt;{471ADD54-6DE1-42F2-8ECD-A41C5C05029E}&lt;/ProjectGuid&gt;
    &lt;OutputType&gt;Library&lt;/OutputType&gt;
    &lt;AppDesignerFolder&gt;Properties&lt;/AppDesignerFolder&gt;
    &lt;RootNamespace&gt;ClassLibrary1&lt;/RootNamespace&gt;
    &lt;AssemblyName&gt;ClassLibrary1&lt;/AssemblyName&gt;
    &lt;TargetFrameworkVersion&gt;v4.5&lt;/TargetFrameworkVersion&gt;
    &lt;FileAlignment&gt;512&lt;/FileAlignment&gt;
    &lt;SccProjectName&gt;SAK&lt;/SccProjectName&gt;
    &lt;SccLocalPath&gt;SAK&lt;/SccLocalPath&gt;
    &lt;SccAuxPath&gt;SAK&lt;/SccAuxPath&gt;
    &lt;SccProvider&gt;SAK&lt;/SccProvider&gt;
    &lt;StyleCopTreatErrorsAsWarnings&gt;false&lt;/StyleCopTreatErrorsAsWarnings&gt;
    &lt;SolutionDir Condition=&quot;$(SolutionDir) == '' Or $(SolutionDir) == '<em>Undefined</em>'&quot;&gt;..\&lt;/SolutionDir&gt;
    &lt;RestorePackages&gt;true&lt;/RestorePackages&gt;
  &lt;/PropertyGroup&gt;

Personalizar las reglas

Una vez que hayamos instalado StyleCop, podemos configurarlo haciendo clic derecho en el proyecto y veremos las reglas y opciones que podemos configurar:

StyleCop SettingsEsto va a generar un archivo en la raíz del proyecto llamado “Settings.Stylecop” que tenedremos que añadir al proyecto y al TFS

No es mala idea usar siempre el mismo archivo de configuración para todos nuestros proyectos, así que una vez que tengamos un archivo de este tipo podemos ponerlo en un directorio dentro del TFS y enlazarlo al archivo de nuestro proyecto en la sección de configuración de StyleCop, en la pestaña “Settings Files” de esta manera:

StyleCop Custom Rules

Esto generará un “Settings.stylecop” tan sólo con la ruta que le hemos indicado. Este archivo también tenemos que añadirlo al TFS para que se ejecute StyleCop en la nube.

Juan María Laó Ramos