Evaluar migración a .NET Core

Tarde o temprano nos encontraremos con la migración de frameworks/tecnologías y .NET no iba a ser una excepción. Utilizaremos la herramienta .NET Portability Analyzer para un primer vistazo a nuestras librerías y aplicaciones teniendo como objetivo aplicaciones multiplataforma, microservicios, dockers… en la nube.

Debemos tener claro antes de empezar, la recomendación general de Microsoft actualmente es utilizar .NET Core si tenemos que añadir nuevas funcionalidades en background, por el momento .NET Framework y .NET Core son complementarias. La mayor parte de las API de .NET Core se comparten con .NET Framework

Aclarado esto, con la extensión para Visual Studio 2019 instalada ya podemos iniciar el análisis que nos ayudará a identificar las dependencias externas. Dentro de la configuración de la extensión podemos fijar nuestro objetivo. Todas las acciones tienen su equivalente en línea de comandos.

Leer más

C# 9: propiedades iniciales y datos

Desde el año 2000 han sido muchas las modificaciones y mejoras en el lenguaje, a veces cuesta acostumbrarse a estas nuevas funcionalidades, veamos que nos depara 20 años después:

Es posible declarar el valor de propiedades en el momento de creación de un objeto, no es posible modificar a posteriori estos valores.

1
2
3
4
5
public class Vehiculo
{
    public string Marca { get; init; }
    public string Modelo { get; init; }
}

Por tanto, si todas las propiedades de un objeto con valores primitivos (int, double…) son de solo lectura (inmutables), nos acercamos a la definición de estructura (struct). Recordemos que las estructuras contienen valores y las clases referencias a valores, el ejemplo básico:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct Vehiculo
    public int Potencia; 
    public Vehiculo(int pot) 
    
        this.Potencia = pot; 
    
 
Vehiculo a = new Vehiculo(120); 
Vehiculo b = a; 
a.Potencia = 200; 
 
System.Console.WriteLine(b.Potencia);
Leer más

ResolveUR: Error durante la instalación

La extensión ResolveUR todavía no tiene el archivo de instalación adaptador a Visual Studio 2019 pero funciona como en versiones anteriores, deberemos adaptar el fichero de instalación VSIX

This extension cannot be installed because the following references are missing: Microsoft.VisualStudio.Component.CoreEditor

Dentro del fichero catalog.json sustituimos:

"Microsoft.VisualStudio.Component.CoreEditor":"[15.0.26208.0,16.0)"}

Por la versión de VS2019:

"Microsoft.VisualStudio.Component.CoreEditor":"[15.0,17.0)"}

Continuará con la ejecución como en versiones anteriores:

Descargar ResolveUR_MOD_VS2019.zip (46,35 kb)

.NET Framework hoy y mañana

En ciertas ocasiones, más habituales de lo que uno desearía, te encuentras en la obligación de interactuar con componentes antiguos… muy antiguos… si hablamos de un COM en Visual Basic 6 nos remitimos 20 años atrás. Si la evolución del software y hardware cada 6 meses puede ser notable, en algunos ámbitos la adopción de ciertos hitos tecnológicos lleva décadas.

Existe una mejora y facilidad de uso entre los Common Language Runtime (CLR), aunque Microsoft le encanta cambiar y variar los nombres (Project K, vNext…) , intentaremos resumir…

Actualmente la definición de .NET Standard intenta facilitar a los desarrolladores una API común para aplicaciones de escritorio, móvil, juegos y cloud, tenemos por un lado Full Framework y por otro lado Core Framework, dos ramas con diferentes propósitos.

  • Full Framework es monolítica, instalas todo o nada solo para Windows
  • Core Framework es modular, puedes referenciar solo las partes que utilices para entorno Windows, Linux o Mac, además es Open Source y con web/Cloud en mente inicialmente.
  • Dejamos Xamarin como multiplataforma a partir de la evolución de Mono (Linux) cuando Microsoft no quería llevar .NET fuera de Windows (eran otros tiempos sin iOS ni Android…)

A futuro Microsoft parece querer unificar toda su tecnología sobre C# en .NET Core: Entity (ORM), WPF, MVC, SignalR, MVC, Web API… pero hasta entonces tenemos largos años de Full Framework todavía ¿cuantos?

 

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.