Antivirus vs Visual Studio Team Services Agent + SonarQube

En entornos de trabajo corporativo en los que se utiliza TFS como herramienta de desarrollo, el análisis estático de código fuente ayuda a obtener métricas sobre calidad de software, para grandes y pequeños proyectos; un punto de partida en el que comparar convenciones sobre: estilo, seguridad, mantenibilidad, complejidad, duplicidad…

En el caso de las compilaciones lanzadas contra el agente de Visual Studio para Team Services, Microsoft lleva tiempo apostando por el Open Source (suena raro todavía decirlo), la automatización del proceso es sencilla.

Nuestro agente VSTS instalado descargará el código fuente configurado en la compilación, en nuestro caso una de las tareas dentro de este flujo, se integra con el anális de SonarQube mediante su plugin correspondiente. Donde obtenemos repetidamente errores:

Después de comprobar permisos, reinstalar agente, configuración del gateway de conexión TFS-SonarQube el enemigo silencioso… el antivirus, en este caso Panda, detectaba: por un lado el archivo temporal generado por el agente como posible Exploit genérico; por la otra parte, el ejecutable creado durante el análisis de código estático bloqueado…

 

Varias preguntas:

¿Por qué la generación de código fuente desde el agente crea un archivo temporal con el mismo nombre, algún tipo de GUID o similar, en todas las ejecuciones?

¿Por qué la heurística cloud (+hardening) de Panda lo analiza, remite y marca como confiable pero lo sigue bloqueando?

ACTUALIZADO: después de comunicar con Panda se solucionó en la segunda actualización específica para este problema.

Visual Studio 201X + Fall Creators Update

Lo que a priori puede parecer alarmante, en equipos de desarrollo con Visual Studio instalado, después de instalar la actualización para Windows 10 Fall Creators Update:

[ArgumentOutOfRangeException: El argumento especificado está fuera del intervalo de valores válidos.
Nombre del parámetro: site]
   System.Web.HttpRuntime.HostingInit(HostingEnvironmentFlags hostingFlags, PolicyLevel policyLevel, Exception appDomainCreationException) +280

 

Se soluciona sencillamente volviendo a instalar IIS desde el Panel de control\Programas\Programas y características en «Activar o desactivar las características de Windows»

 

Podremos volver a depurar proyectos web en tiempo real sin necesidades de reiniciar. Por algún motivo desconocido durante el proceso se desactiva.

 

TIP: debug Linq SQL

TIP: debug Linq SQL

En ocasiones podemos encontrar sentencias complejas o sin errores aparentes, otra forma de intentar buscar soluciones es mostrar la sentencial SQL generada por Entity Framework. Tan solo debemos habilitar el log, mostrandolo en en panel Output de nuestro Visual Studio por ejemplo:

                using (ModeloEntities entidad = new ModeloEntities ())
                {

                    entidad.Database.Log = s => System.Diagnostics.Debug.WriteLine(s);
                    var resultado = (nuestraConsultaLINQ)

                }

NOTA: puedes recupera la ventana de salida con CTRL + ALT + O

Errores JavaScript en entornos de prueba locales: Browser Link

En ocasiones es posible obtener errores en entornos de desarrollo, pero una vez en producción no suceden; este puede ser uno de los motivos dependiendo del caso. A partir de la versión Visual Studio 2013 se introdujo una características nueva: Browser Link que permite interceptar las llamadas AJAX mediante SignalR estableciendo una canal intermedio entre Visual Studio y el navegador.

Para tal función se inserta automáticamente código JavaScript en la página generada que puede llegar a interferir, por ejemplo con Bootstrap o controles de terceros, generando el error en tiempo de ejecución del tipo:

La prueba rápida es deshabilitar esta característica desde el propio entorno VS:

En entornos de producción con la compilación fuera del modo debug no se realiza la carga de esta característica, solo sobre localhost.

<system.web>
  <compilation debug="false" targetFramework="4.5" />
</system.web>

 

Actualizar modelo .edmx con los cambios de la base de datos

La realización de cambios en la base de datos debe reflejarse dentro del modelo generado en Visual Studio. Desde un cambio mínimo, por ejemplo un campo de una tabla determinada pasa a admitir valores nulos, a cualquier otro complejo de adición/modificación/eliminación de tablas, referencias, triggers, procedimientos, relaciones…

1.- Abrimos nuestro archivo edmx con el editor predeterminado de Visual Studio: ADO.NET Entity Data Model Designer y pulsamos con el botón derecho sobre una zona libre en la opción «Udate Model from Database»

2.- Una vez que tenemos nuestro modelo reflejado, actualizamos el fichero con extensión «IntranetModel.TT» pulsando con el botón derecho sobre ellos y seleccionado «Run custom tool»

3.- Lanzamos «Run custom tool» sobre el fichero «IntranetModel.context.TT»

En el caso de haber cambiado el namespace o el nombre del proyecto, deberemos renombrarlos de nuevo en el archivo CS correspondiente del context de la clase. Tambien es posible realizar cambios parciales en partes concretar del modelado desde «Model browser«.

NOTA 1: Si a pesar de ello, no se reflejan los cambios, podemos eliminar ambos ficheros y volver a añadir «Add code generation item» seleccionando la versión correspondiente de «EF 6.x DbContext Generator»

NOTA 2: En ocasiones al actualizar un tipo de dato, es posible que no se refleje correctamente en el modelo EDMX, por ejemplo, el paso de un campo de string a bintint (int64). Revise manualmente los posibles cambios y vuelve a realizar el proceso.