Archivo de la etiqueta: Visual Studio

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();

        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 > 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 & InstanceState.Local) != InstanceState.Local
                    || (state & InstanceState.Registered) != InstanceState.Registered)
                {
                    continue;
                }

                var msBuildComponent =
                    instance2.GetPackages()
                        .FirstOrDefault(
                            p =>
                                p.GetId()
                                    .Equals("Microsoft.Component.MSBuild",
                                        StringComparison.InvariantCultureIgnoreCase));

                if (msBuildComponent == null)
                {
                    continue;
                }

                var instanceRootDirectory = instance2.GetInstallationPath();

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

                if (File.Exists(msbuildPathInInstance))
                {
                    return msbuildPathInInstance;
                }
            }
        } while (fetched > 0);

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

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. Sigue leyendo

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

 

Nuevas funcionalidades sobre testing en la interfaz Web de TFS

Vamos a ver una nueva funcionalidad que aún no he usado y me ha dejado enamorado.

Se trata de crear casos de test's a partir de un archivo Excel en TFS con la interfaz web.

Primero, tendremos que crear un plan de tests, en la pestaña "Test" y creamos un nuevo "Test plan" haciendo clic en el "+":

1. Los Test Plans y Suites son work items
Sigue leyendo

[ebook] Guías de Visual Studio Version Control [ALMRangers]

ALMRangers

Los Visual Studio ALM Rangers ofrecen una guía profesional, experiencia práctica y proporcionan soluciones a la comunidad ALM. Son un grupo especial compuesto por miembros del grupo de producto de Visual Studio, de Microsoft Services, Microsoft Most Valuable Professionals (MVP) y Visual Studio Community Leads. La información sobre sus miembros está disponible aquí online.

Hace un tiempo me lancé a traducir una guía que escribieron que me pareció muy interesante: Testing Unitario con Microsoft Fakes. (Hace poco lanzaron la segunda revisión y también actualicé la versión que traduje.

En estas últimas semanas he estado trabajando en otras traducciones de otras guías sobre Visual Studio Version Control y todas sus funcionalidades:

EstrategiasDeBranching JoyasTFVCGestionDependenciasNuGet

Espero que os resulten interesantes.

[Updated]

Aquí tenéis los enlaces directos a los pdfs a las traducciones:

Post en el blog de Willy-Peter Schaub

Juan María Laó Ramos

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 Sigue leyendo

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.

StyleCop

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:

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

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

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.

Están locos estos de Redmond

Vaya sorpresa que me acabo de llevar, y es que en Redmond hacen las cosas a lo grande. Si ayer anunciaron el nuevo servicio Outlook.com, hoy, hace apenas unos minutos han anunciado:

  • Windows Store: Han abierto la Windows Store para poder empezar a mandar nuestras apps para Windows 8.
  • Windows 8: Han publicado la última release RTM de Windows 8.
  • Visual Studio 2012 y .NET 4.5: Ya han llegado a las últimas builds de Visual Studio y lo lanzarán en Septiembre, pero el 15 de agosto estará disponible para los suscriptores de MSDN.

¡Se nota que estamos en verano y la cosa está que arde!

CodeFluent Entities. Nunca el DDD fué tan fácil

Vamos a ver en este post es un producto que he encontrado y parece muy prometedor. CodeFluent Entities es una herramienta de modelado que nos permite generar y mantener actualizadas todas las layers y capas de nuestra aplicación. Asegurando el conjunto de buenas prácticas arquitecturales en nuestros sistemas desde su nacimiento. Esto es, han creado una herramienta para aplicar Domain Driven Development sin que apenas nos demos cuenta.

La he estado probando un tiempo y la verdad me ha dejado sorprendido, pensé en un momento que iba a ser un ORM más, pero luego descubrí el modelador de objetos de negocio, seguido de la generación de servicios RESTful, la sencillez de enlazar el modelo de negocio con las interfaces de usuario ASP.NET Web Forms, WPF y Windows Forms (están trabajando en los conectores para ASP.NET MVC, Silverlight). Sigue leyendo

Mejoras del editor de CSS en Visual Studio

Este es el séptimo de una serie de post sobre ASP.NET 4.5

Las próximas releases de .NET y Visual Studio incluyen un montón de nuevas características. Con ASP.NET 4.5 veremos mejoras realmente increíbles tanto en Web Forms como en MVC, así como en el núcleo de ASP.NET en el que se sustentan ambas tecnologías.

En el post de hoy veremos algunas de las mejoras que traerá Visual Studio que hacen del trabajo con CSS y CSS3 se más sencillo en proyectos ASP.NET Sigue leyendo

Publicación en desarrolloweb.com

Me llena de orgullo y satisfacción anunciar mi primera publicación en desarrolloweb.com.

Un artículo sobre cómo podemos aprovecharnos de las herramientas de análisis estático de código:

http://www.desarrolloweb.com/articulos/mejorar-codigo-visual-studio.html

Espero que os sirva.

Juan María Laó Ramos

Extensión de Visual Studio: Web Essentials de Mads Kristensen

Visual Studio 2010 es muy extensible y ha permitido a mucha gente del equipo a que prueben nuevas caracteríticas para del desarrollo web sin tener que recompilar Visual Studio. Una de esas extensiones es "Web Essentials" que ha hecho Mads Kristensen. Mads es el que se encarga de las herramientas de HTML5 y CSS3 en nuestro equipo. Sigue leyendo

Mejora tu código, código, código (III)

Continuamos con la mini serie sobre análisis estático de código con el último post de la serie.

Aquí tenéis el enlace al primero y al segundo.

Y es que en los anteriores post no hemos visto el trato con el código heredado o legacy code (ese gran hijo de ...). Y es que es un handicap muy común en nuestro día a día.

Si este código heredado no tiene contratos, vamos a obtener algunos warnings molestos del Static Checker. Sin embargo, la API de Code Contracts nos ofrece un pequeño workarround sobre esto.

Básicamente, este tipo de warnings son debidos a la falta de información - el Checker no es capaz de encontrar la información necesaria. Sin embargo, podemos dar algunos detalles.

Vamos a mirar el siguiente código:

Código con un Warning

Código con un Warning

El checker nos avisa de una posible referencia nula. Aparentemente la variable context está siendo usada sin haber sido inicializada. ¿Quién es el responsable del warning, el Checker u otra cosa?

En este caso, el aviso lo está dando ReSharper, cuyo motor de análisis identifica una posible referencia nula. ¿Pero porqué no nos lo da el Checker?, la respuesta es por la línea:

Contract.Assume(context!=null);

Y es que con esa línea le estamos diciendo al Checker que la variable context nunca va a ser nula. El Checker confía en nosotros y añade esa información a sus procesos. Resharper no ofrece soporte completo a los contratos de .NET, de ahí el aviso. Sin embargo, ReSharper soporta su propio sistema de anotaciones que podéis usar de la misma manera. Si queréis ver más detalles pasáos por aquí.

Uso óptimo del análisis estático de código.

El análisis estático es complejo, y no suele ser una ciencia exacta. Suele ocurrir que rellenamos nuestro código con información de contratos con la mejor intención, sólo para hacer que el tiempo de compilación se dispare. Para esto hay un par de soluciones que podríamos tomar para optimizar el uso de contratos y los análisis siguientes.

La primera es crear una configuración de compilación especial y habilitar las comprobaciones sólo en esa configuración. Compilamos en esa configuración de vez en cuando para obtener información, la corregimos los posibles problemas y continuamos trabajando sin el análisis estático.

La segunda es probar a usar contratos poco a poco. Aplicamos contratos de manera extensiva en el código, pero deshabilitamos los contratos a nivel de assembly. Esto lo asemos añadiendo el siguiente atributo en las propiedades del assembly:

[assembly:ContractVerification(false)]

Lo siguiente, es re-habilitar el checkeo de contratos sólo cuando estemos centrados en clases, métodos o assemblies.

Aviso

El análisis estático de código es una técnica que intenta evaluar el correcto funcionamiento de vuestro código sin ejecutarlo. Hay algunas herramientas que hacen esto. La primera es el compilador, otra es el Static Checker - un ejecutable que se integra en el proceso de compilación. En .NET, una herramienta especial aprende desde los contratos que tengáis, evalúa la información y nos muestra posibles errores y violaciones de contratos.

En el momento en el que la complejidad aumenta continuamente y el equipo de desarrollo se va quedando sin tiempo, integrar este tipo de herramientas salva algún tiempo de compilación, pero más importante, nos protege de errores feos en nuestro software.

 

Juan María Laó Ramos.

Imagen de la configuración de static checker

Mejora tu código, código, código (II)

Hace dos días vimos una pequeña introducción sobre las herramientas de análisis estático de código.

Hoy vamos a ver un poco lo que ofrece Visual Studio 2010 y .NET 4 junto a la herramienta Static Checker  creada por el equipo de Contratos de código. Sigue leyendo

Project Templates y variables de entorno

Los Project Templates o Plantillas de Proyecto de Visual Studio tienen muchas curiosidades. He tenido que meterme en ese pequeño submundo y me gustaría compartir lo que he aprendido, que no es mucho.

Todas las plantillas de proyectos se suelen encontrar en: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplatesencuentran  vamos, el directorio de instalación de VS. Sigue leyendo