Marco de trabajo .NET

La Infraestructura de Lenguaje Común (CLI) proporciona una plataforma independiente del lenguaje para el desarrollo y la ejecución de aplicaciones. Al implementar los aspectos centrales de .NET Framework dentro del ámbito de CLI, estas funciones no estarán ligadas a un solo lenguaje, sino que estarán disponibles en los numerosos lenguajes compatibles con el framework.

.NET Framework incluye el Common Language Runtime (CLR). Este actúa como motor de ejecución de .NET Framework y ofrece numerosos servicios, como gestión de memoria , seguridad de tipos , manejo de excepciones , recolección de basura , seguridad y gestión de subprocesos . Todos los programas escritos para .NET Framework son ejecutados por el CLR.

Los programas escritos para .NET Framework se compilan en código CIL (Common Intermediate Language), en lugar de compilarse directamente en código máquina . Durante la ejecución, un compilador JIT ( Just-In-Time ) específico de la arquitectura convierte el código CIL en código máquina.

El código CLI compilado se almacena en ensamblados CLI . Según lo estipulado en la especificación, los ensamblados se almacenan en formato de archivo ejecutable portátil (PE), común en la plataforma Windows para todas las bibliotecas de vínculos dinámicos (DLL) y los archivos ejecutables EXE . Cada ensamblado consta de uno o más archivos, uno de los cuales debe contener un manifiesto con los metadatos del ensamblado. El nombre completo de un ensamblado (que no debe confundirse con el nombre del archivo en el disco) incluye su nombre de texto simple, número de versión, configuración regional y token de clave pública . Los ensamblados se consideran equivalentes si comparten el mismo nombre completo.

El creador del ensamblado también puede usar una clave privada para la nomenclatura segura . El token de clave pública determina la identidad real del firmante del ensamblado. Solo quienes conocen su clave privada (del sistema de criptografía de doble clave) pueden firmar ensamblados que tengan la misma nomenclatura segura que una versión anterior del ensamblado. La nomenclatura segura es necesaria para agregar ensamblados a la caché global de ensamblados .

A partir de Visual Studio 2015, la tecnología de compilación .NET Native permite compilar el código .NET de las aplicaciones de la Plataforma universal de Windows directamente a código máquina en lugar de código CIL, pero la aplicación debe estar escrita en C# o Visual Basic.NET. ^{[ 18 ]}

.NET Framework incluye una implementación de las bibliotecas estándar fundamentales de la CLI . La biblioteca de clases de .NET Framework (FCL) está organizada en una jerarquía de espacios de nombres. La mayoría de las interfaces de programación de aplicaciones (API) integradas forman parte de los espacios de nombres System.*o Microsoft.*. Estas bibliotecas de clases implementan muchas funciones comunes, como la lectura y escritura de archivos, la representación gráfica, la interacción con bases de datos y la manipulación de documentos XML. Las bibliotecas de clases están disponibles para todos los lenguajes compatibles con la CLI . La FCL implementa la biblioteca de clases base (BCL) de la CLI y otras bibliotecas de clases; algunas son especificadas por la CLI y otras son específicas de Microsoft.

BCL incluye un pequeño subconjunto de toda la biblioteca de clases y es el conjunto central de clases que sirven como la API básica de CLR. ^{[ 19 ]} Para .NET Framework, la mayoría de las clases consideradas parte de BCL residen en y mscorlib.dll. Las clases de BCL están disponibles en .NET Framework, así como en las implementaciones alternativas de CLI, incluyendo .NET Compact Framework , Microsoft Silverlight , .NET Core y Mono .System.dllSystem.Core.dll

FCL se refiere a la biblioteca de clases completa que viene con .NET Framework. Incluye BCL, un conjunto ampliado de bibliotecas, como Windows Forms , ASP.NET y Windows Presentation Foundation (WPF), así como extensiones a las bibliotecas de clases base ADO.NET , Language Integrated Query (LINQ), Windows Communication Foundation (WCF) y Workflow Foundation (WF). FCL tiene un alcance mucho mayor que las bibliotecas estándar de lenguajes como C++ y es comparable en alcance a las bibliotecas estándar de Java .

Con la introducción de implementaciones alternativas de CLI (por ejemplo, Silverlight), Microsoft introdujo el concepto de Bibliotecas de Clases Portátiles (PCL), que permite que una biblioteca consumidora se ejecute en más de una implementación. Con la proliferación de implementaciones, el enfoque PCL no logró escalar (las PCL se definen como intersecciones de la superficie de API entre dos o más implementaciones). ^{[ 20 ]} Como siguiente paso evolutivo de PCL, se creó retroactivamente la Biblioteca .NET Standard, basada en las System.Runtime.dllAPI existentes en UWP y Silverlight. Se recomienda a las nuevas implementaciones de CLI que implementen una versión de la Biblioteca Standard, lo que les permite ejecutar bibliotecas de terceros existentes sin necesidad de crear nuevas versiones. La Biblioteca .NET Standard permite una evolución independiente de las capas de la biblioteca y del modelo de aplicación dentro de la arquitectura .NET. ^{[ 21 ]}

NuGet es el gestor de paquetes para todas las plataformas .NET. Se utiliza para obtener bibliotecas de terceros en un proyecto .NET mediante una fuente de bibliotecas global en NuGet.org. ^{[ 22 ]} Las fuentes privadas pueden mantenerse por separado, por ejemplo, mediante un servidor de compilación o un directorio del sistema de archivos.

Microsoft introdujo C++/CLI en Visual Studio 2005, que es un lenguaje y un método para compilar programas de Visual C++ para que se ejecuten dentro del .NET Framework. Algunas partes del programa C++ todavía se ejecutan dentro de un Visual C++ Runtime no administrado, mientras que las partes especialmente modificadas se traducen a código CIL y se ejecutan con el CLR del .NET Framework .

Los ensamblados compilados con el compilador C++/CLI se denominan ensamblados de modo mixto, ya que contienen código nativo y administrado en la misma DLL. ^{[ 23 ]} Estos ensamblados son más complejos de analizar mediante ingeniería inversa, ya que los descompiladores de .NET , como .NET Reflector, solo revelan el código administrado.

Dado que los sistemas informáticos suelen requerir la interacción entre aplicaciones nuevas y antiguas, .NET Framework proporciona mecanismos para acceder a las funciones implementadas en programas nuevos y antiguos que se ejecutan fuera del entorno .NET. El acceso a los componentes del Modelo de Objetos Componentes (COM) se proporciona en System.Runtime.InteropServiceslos System.EnterpriseServicesespacios de nombres del framework. El acceso a otras funciones se realiza mediante los Servicios de Invocación de Plataforma (P/Invoke). El acceso a las funciones .NET desde aplicaciones nativas se realiza mediante la función inversa de P/Invoke.

.NET Framework introduce un Sistema de Tipos Comunes (CTS) que define todos los tipos de datos y construcciones de programación compatibles con CLR, así como la forma en que interactúan, de acuerdo con las especificaciones de la CLI. Gracias a esta característica, .NET Framework permite el intercambio de tipos e instancias de objetos entre bibliotecas y aplicaciones escritas en cualquier lenguaje compatible con la CLI .

CTS y el CLR utilizados en .NET Framework también garantizan la seguridad de tipos . Esto evita conversiones de tipo mal definidas, invocaciones de métodos incorrectas y problemas de tamaño de memoria al acceder a un objeto. Además, esto hace que la mayoría de los lenguajes de la CLI sean de tipado estático (con o sin inferencia de tipos ). Sin embargo, a partir de .NET Framework 4.0, el Dynamic Language Runtime extendió el CLR, lo que permitió implementar lenguajes de tipado dinámico sobre la CLI.

Aunque Microsoft nunca ha implementado el marco completo en ningún sistema excepto Microsoft Windows, lo ha diseñado para que sea multiplataforma, ^{[ 24 ]} y existen implementaciones disponibles para otros sistemas operativos (véase Silverlight y § Implementaciones alternativas ). Microsoft presentó las especificaciones para CLI (que incluye las bibliotecas de clases base, CTS y CIL), ^{[ 25 ] [ 26 ] [ 27 ]} C# , ^{[ 5 ]} y C++/CLI ^{[ 28 ]} tanto a Ecma International (ECMA) como a la Organización Internacional de Normalización (ISO), convirtiéndolas en estándares oficiales. Esto permite a terceros crear implementaciones compatibles del marco y sus lenguajes en otras plataformas.

.NET Core multiplataforma (anteriormente .NET Core) también está disponible oficialmente para muchas distribuciones de Linux y macOS. ^{[ 29 ]}

.NET Framework cuenta con su propio mecanismo de seguridad, que incluye dos características principales: Seguridad de Acceso al Código (CAS) y validación y verificación. CAS se basa en la evidencia asociada a un ensamblado específico. Normalmente, esta evidencia proviene del origen del ensamblado (ya sea que esté instalado en la máquina local o se haya descargado de Internet). CAS utiliza esta evidencia para determinar los permisos otorgados al código. Cuando un código requiere un permiso específico, CLR realiza un recorrido por la pila de llamadas, comprobando si cada ensamblado de cada método posee el permiso requerido. Si algún ensamblado no tiene el permiso, se generará una excepción de seguridad.

El bytecode CIL administrado es más fácil de aplicar ingeniería inversa que el código nativo, a menos que esté ofuscado . ^{[ 30 ]} Los programas descompiladores de .NET permiten a los desarrolladores sin habilidades de ingeniería inversa ver el código fuente detrás de los ensamblados .NET no ofuscados. Por el contrario, las aplicaciones compiladas a partir de código máquina nativo son mucho más difíciles de aplicar ingeniería inversa, y el código fuente casi nunca se produce con éxito, principalmente debido a las optimizaciones del compilador y la falta de reflexión . ^{[ 31 ]} Esto crea preocupaciones en la comunidad empresarial sobre la posible pérdida de secretos comerciales y la elusión de los mecanismos de control de licencias. Para mitigar esto, Microsoft ha incluido Dotfuscator Community Edition con Visual Studio .NET desde 2002. ^{[ b ]} También hay herramientas de ofuscación de terceros disponibles de proveedores como VMware , Vi Labs, Turbo y Red Gate Software . Hay herramientas de cifrado a nivel de método para código .NET disponibles de proveedores como SafeNet .

CLR libera al desarrollador de la carga de administrar la memoria (asignarla y liberarla cuando sea necesario); se encarga de la administración de la memoria al detectar cuándo se puede liberar de forma segura. Las instancias de tipos .NET (objetos) se asignan desde el montón administrado, un grupo de memoria administrado por CLR. Mientras exista una referencia a un objeto, ya sea directa o a través de un grafo de objetos, se considera que el objeto está en uso. Cuando no existe ninguna referencia a un objeto y no se puede acceder a él ni utilizarlo, se convierte en basura y se elimina mediante la recolección de basura.

.NET Framework incluye un recolector de basura (GC) que se ejecuta periódicamente, en un hilo separado del hilo de la aplicación, que enumera todos los objetos inutilizables y recupera la memoria asignada a ellos. Es un recolector de basura no determinista, compactador, de marcado y barrido . GC se ejecuta solo cuando se ha utilizado una cantidad determinada de memoria o hay suficiente presión de memoria en el sistema. Dado que no se garantiza cuándo se alcanzan las condiciones para recuperar la memoria, las ejecuciones de GC no son deterministas . Cada aplicación .NET tiene un conjunto de raíces, que son punteros a objetos en el montón administrado ( objetos administrados ). Estos incluyen referencias a objetos estáticos, objetos definidos como variables locales o parámetros de método actualmente en el ámbito, y objetos a los que se refieren los registros de la CPU. ^{[ 32 ]} Cuando GC se ejecuta, pausa la aplicación y luego, para cada objeto al que se refiere la raíz, enumera recursivamente todos los objetos alcanzables desde los objetos raíz y los marca como alcanzables. Utiliza metadatos de CLI y reflexión para descubrir los objetos encapsulados por un objeto y luego recorrerlos recursivamente. Luego enumera todos los objetos en el montón (que inicialmente se asignaron contiguos) usando reflexión. Todos los objetos no marcados como alcanzables son basura. ^{[ 32 ]} Esta es la fase de marcado . ^{[ 33 ]} Dado que la memoria ocupada por la basura no tiene consecuencias, se considera espacio libre. Sin embargo, esto deja bloques de espacio libre entre objetos que inicialmente eran contiguos. Luego, los objetos se compactan para que el espacio libre en el montón administrado vuelva a ser contiguo. ^{[ 32 ] [ 33 ]} Cualquier referencia a un objeto invalidada por el movimiento del objeto es actualizada por GC para reflejar la nueva ubicación. ^{[ 33 ]} La aplicación se reanuda después de que finaliza la recolección de basura. La última versión del marco .NET utiliza la recolección de basura concurrente junto con el código del usuario, lo que hace que las pausas sean imperceptibles, porque se realiza en segundo plano. ^{[ 34 ]}

El recolector de basura utilizado por .NET Framework también es generacional . ^{[ 35 ]} A los objetos se les asigna una generación . Los objetos recién creados se etiquetan como Generación 0. Los objetos que sobreviven a una recolección de basura se etiquetan como Generación 1. Los objetos de Generación 1 que sobreviven a otra recolección son Generación 2. El framework utiliza hasta objetos de Generación 2. ^{[ 35 ]} Los objetos de generaciones superiores se recolectan con menos frecuencia que los objetos de generaciones inferiores. Esto aumenta la eficiencia de la recolección de basura, ya que los objetos más antiguos tienden a tener una vida útil más larga que los objetos más nuevos. ^{[ 35 ]} Al ignorar los objetos más antiguos en la mayoría de las ejecuciones de recolección, se necesitan menos comprobaciones y operaciones de compactación en total. ^{[ 35 ]}

Cuando se inicia una aplicación por primera vez, .NET Framework compila el código CIL en código ejecutable mediante su compilador justo a tiempo y almacena en caché el programa ejecutable en la caché de imágenes nativas de .NET. ^{[ 36 ] [ 37 ]} Gracias al almacenamiento en caché, la aplicación se inicia más rápido en los lanzamientos posteriores, aunque el primer lanzamiento suele ser más lento. Para acelerar el primer lanzamiento, los desarrolladores pueden usar la utilidad Generador de imágenes nativas para compilar y almacenar en caché manualmente cualquier aplicación .NET con antelación . ^{[ 37 ]}

El recolector de basura, que está integrado en el entorno, puede introducir retrasos imprevistos en la ejecución sobre los que el desarrollador tiene poco control directo. "En aplicaciones grandes, la cantidad de objetos con los que el recolector de basura necesita trabajar puede llegar a ser muy grande, lo que significa que puede llevar mucho tiempo recorrerlos y reorganizarlos todos." ^{[ 38 ]}

.NET Framework ofrece soporte para llamar a Streaming SIMD Extensions (SSE) mediante código administrado desde abril de 2014 en Visual Studio 2013 Update 2. Sin embargo, Mono ha ofrecido soporte para SIMD Extensions desde la versión 2.2 dentro del espacio de nombres Mono.Simd en 2009. ^{[ 39 ]} El desarrollador principal de Mono, Miguel de Icaza, ha expresado su esperanza de que este soporte SIMD sea adoptado por el estándar ECMA de CLR. ^{[ 40 ]} Streaming SIMD Extensions ha estado disponible en las CPU x86 desde la introducción del Pentium III . Algunas otras arquitecturas, como ARM y MIPS, también tienen extensiones SIMD. En caso de que la CPU no sea compatible con esas extensiones, las instrucciones se simulan en software. ^{[ 41 ] [ 42 ]}