.NET Framework (pronunciado como " punto net ") es un marco de software propietario desarrollado por Microsoft que se ejecuta principalmente en Microsoft Windows . Fue la implementación predominante de Common Language Infrastructure (CLI) hasta que fue reemplazada por el proyecto multiplataforma .NET . Incluye una gran biblioteca de clases llamada Framework Class Library (FCL) y proporciona interoperabilidad de lenguajes (cada lenguaje puede usar código escrito en otros lenguajes) en varios lenguajes de programación . Los programas escritos para .NET Framework se ejecutan en un entorno de software (a diferencia de un entorno de hardware ) denominado Common Language Runtime (CLR). CLR es una máquina virtual de aplicaciones que proporciona servicios como seguridad, administración de memoria y manejo de excepciones . Como tal, el código informático escrito con .NET Framework se denomina " código administrado ". FCL y CLR juntos constituyen .NET Framework.
FCL proporciona la interfaz de usuario , acceso a datos , conectividad de bases de datos , criptografía , desarrollo de aplicaciones web , algoritmos numéricos y comunicaciones de red . Los programadores producen software combinando su código fuente con .NET Framework y otras bibliotecas. El marco está diseñado para ser utilizado por la mayoría de las aplicaciones nuevas creadas para la plataforma Windows. Microsoft también produce un entorno de desarrollo integrado para software .NET llamado Visual Studio .
.NET Framework comenzó como software propietario , aunque la firma trabajó para estandarizar la pila de software casi de inmediato, incluso antes de su primer lanzamiento. A pesar de los esfuerzos de estandarización, los desarrolladores, principalmente aquellos en las comunidades de software libre y de código abierto , expresaron su malestar con los términos seleccionados y las perspectivas de cualquier implementación libre y de código abierto, especialmente en lo que respecta a las patentes de software . Desde entonces, Microsoft ha cambiado el desarrollo de .NET para seguir más de cerca un modelo contemporáneo de proyecto de software desarrollado por la comunidad, incluida la publicación de una actualización de su patente que promete abordar las preocupaciones. [2]
En abril de 2019, Microsoft lanzó .NET Framework 4.8, la última versión principal del marco como oferta propietaria, seguida de .NET Framework 4.8.1 en agosto de 2022. Desde entonces, solo se han publicado correcciones mensuales de errores de seguridad y confiabilidad para esa versión. . No están previstos más cambios en esa versión. .NET Framework seguirá incluyéndose en futuras versiones de Windows y seguirá recibiendo actualizaciones de seguridad, sin planes de eliminarlo a partir de noviembre de 2023. [3]
Microsoft comenzó a desarrollar .NET Framework a finales de los años 1990, originalmente bajo el nombre de Next Generation Windows Services (NGWS), como parte de la estrategia .NET . A principios de 2000, se lanzaron las primeras versiones beta de .NET 1.0.
En agosto de 2000, Microsoft e Intel trabajaron para estandarizar Common Language Infrastructure (CLI) y C# . En diciembre de 2001, ambos habían ratificado las normas ECMA . [4] [5] La Organización Internacional de Normalización (ISO) siguió en abril de 2003. La versión actual de las normas ISO es ISO/IEC 23271:2012 e ISO/IEC 23270:2006. [6] [7]
Si bien Microsoft y sus socios poseen patentes para CLI y C#, ECMA e ISO exigen que todas las patentes esenciales para la implementación estén disponibles en " términos razonables y no discriminatorios ". Las empresas acordaron cumplir estos términos y hacer que las patentes estén disponibles libres de regalías. Sin embargo, esto no se aplicaba a la parte de .NET Framework no cubierta por los estándares ECMA-ISO, que incluían Windows Forms , ADO.NET y ASP.NET . Las patentes que Microsoft posee en estas áreas pueden haber disuadido las implementaciones del marco completo que no son de Microsoft. [8]
El 3 de octubre de 2007, Microsoft anunció que el código fuente de las bibliotecas .NET Framework 3.5 estaría disponible bajo la licencia fuente de referencia de Microsoft (Ms-RSL [a] ). [9] El repositorio de código fuente estuvo disponible en línea el 16 de enero de 2008 e incluía BCL, ASP.NET, ADO.NET, Windows Forms, WPF y XML. Scott Guthrie de Microsoft prometió que se agregarían bibliotecas LINQ, WCF y WF. [10]
Las variantes .NET Compact Framework y .NET Micro Framework de .NET Framework brindaron soporte para otras plataformas de Microsoft como Windows Mobile , Windows CE y otros dispositivos integrados con recursos limitados. Silverlight brindó soporte para navegadores web a través de complementos.
En noviembre de 2014, Microsoft también produjo una actualización de sus concesiones de patentes, que amplía aún más el alcance más allá de sus promesas anteriores. Proyectos anteriores como Mono existían en un área legal gris porque las subvenciones anteriores de Microsoft se aplicaban sólo a la tecnología en "especificaciones cubiertas", incluidas estrictamente las cuartas ediciones de ECMA-334 y ECMA-335. La nueva promesa de patente, sin embargo, no impone ningún límite a la versión de especificación e incluso se extiende a cualquier tecnología de tiempo de ejecución .NET documentada en MSDN que no haya sido especificada formalmente por el grupo ECMA, si un proyecto decide implementarlas. Esto permite que Mono y otros proyectos mantengan la paridad de funciones con las funciones .NET modernas que se han introducido desde que se publicó la cuarta edición sin correr el riesgo de litigios de patentes sobre la implementación de esas funciones. La nueva concesión mantiene la restricción de que cualquier implementación debe mantener un cumplimiento mínimo con las partes obligatorias de la especificación CLI. [11]
El 31 de marzo de 2016, Microsoft anunció en Microsoft Build que volverían a otorgar la licencia completa de Mono bajo una licencia MIT incluso en escenarios en los que anteriormente se necesitaba una licencia comercial. [12] Microsoft también complementó su promesa anterior de patentes para Mono, afirmando que no harán valer ninguna "patente aplicable" contra partes que estén "usando, vendiendo, ofreciendo a la venta, importando o distribuyendo Mono". [13] [14] Se anunció que el Proyecto Mono fue contribuido a la Fundación .NET. Estos desarrollos siguieron a la adquisición de Xamarin , que comenzó en febrero de 2016 y finalizó el 18 de marzo de 2016. [15]
El comunicado de prensa de Microsoft destaca que el compromiso multiplataforma ahora permite una pila .NET del lado del servidor moderna y de código abierto. Microsoft lanzó el código fuente para WPF, Windows Forms y WinUI el 4 de diciembre de 2018. [16]
Common Language Infrastructure (CLI) proporciona una plataforma neutral en cuanto al idioma para el desarrollo y la ejecución de aplicaciones. Al implementar los aspectos centrales de .NET Framework dentro del alcance de CLI, estas funciones no estarán vinculadas a un solo idioma, sino que estarán disponibles en los numerosos idiomas admitidos por el marco.
.NET Framework incluye Common Language Runtime (CLR). Sirve como motor de ejecución de .NET Framework y ofrece muchos servicios como administración de memoria , seguridad de tipos , manejo de excepciones , recolección de basura , seguridad y administración de subprocesos . Todos los programas escritos para .NET Framework son ejecutados por CLR.
Los programas escritos para .NET Framework se compilan en código de lenguaje intermedio común (CIL), en lugar de compilarse directamente en código de máquina . Durante la ejecución, un compilador justo a tiempo (JIT) específico de la arquitectura convierte el código CIL en código de máquina.
El código CIL compilado se almacena en ensamblajes CLI . Según lo dispuesto por 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 archivos EXE ejecutables . Cada ensamblaje consta de uno o más archivos, uno de los cuales debe contener un manifiesto con los metadatos del ensamblaje. El nombre completo de un ensamblado (que no debe confundirse con el nombre del archivo en el disco) contiene su nombre de texto simple, número de versión, referencia cultural y token de clave pública . Las asambleas se consideran equivalentes si comparten el mismo nombre completo.
El creador del ensamblado también puede utilizar una clave privada para crear nombres seguros . El token de clave pública determina la identidad real del firmante del ensamblado. Sólo quien conoce su clave privada (del sistema de criptografía de doble clave) puede firmar ensamblados que tengan el mismo nombre seguro que un ensamblado de versión anterior. Se requiere una denominación segura para agregar ensamblados a la caché de ensamblados global .
A partir de Visual Studio 2015, la tecnología de compilación .NET Native permite la compilación de código .NET de aplicaciones de la Plataforma universal de Windows directamente en código de máquina en lugar de código CIL, pero la aplicación debe estar escrita en C# o Visual Basic.NET. [17]
.NET Framework incluye una implementación de las bibliotecas estándar fundamentales de 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 espacios de nombres System.*o Microsoft.*. Estas bibliotecas de clases implementan muchas funciones comunes, como lectura y escritura de archivos, representación gráfica, interacción de bases de datos y manipulación de documentos XML. Las bibliotecas de clases están disponibles para todos los idiomas compatibles con CLI . FCL implementa la biblioteca de clases base (BCL) de CLI y otras bibliotecas de clases; algunas están especificadas por CLI y otras son específicas de Microsoft.
BCL incluye un pequeño subconjunto de toda la biblioteca de clases y es el conjunto principal de clases que sirven como API básica de CLR. [18] Para .NET Framework, la mayoría de las clases consideradas parte de BCL residen en mscorlib.dll, System.dlly System.Core.dll. Las clases BCL están disponibles en .NET Framework, así como en implementaciones alternativas de CLI, incluidas .NET Compact Framework , Microsoft Silverlight , .NET Core y Mono .
FCL se refiere a toda la biblioteca de clases que se incluye con .NET Framework. Incluye BCL, un conjunto ampliado de bibliotecas, que incluye Windows Forms , ASP.NET y Windows Presentation Foundation (WPF), y también extensiones de 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 para lenguajes como C++ y es comparable en alcance a las bibliotecas estándar de Java .
Con la introducción de implementaciones CLI alternativas (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 mayor proliferación de implementaciones, el enfoque PCL no logró escalar (las PCL son intersecciones definidas de la superficie API entre dos o más implementaciones). [19] Como siguiente paso evolutivo de PCL, la biblioteca estándar .NET se creó retroactivamente basándose en las System.Runtime.dllAPI basadas en UWP y Silverlight. Se recomienda que las nuevas implementaciones de CLI implementen una versión de la biblioteca estándar que les permita ejecutar bibliotecas de terceros existentes sin necesidad de crear nuevas versiones de ellas. La biblioteca estándar .NET permite una evolución independiente de las capas de biblioteca y modelo de aplicación dentro de la arquitectura .NET. [20]
NuGet es el administrador de paquetes para todas las plataformas .NET. Se utiliza para recuperar bibliotecas de terceros en un proyecto .NET con una fuente de biblioteca global en NuGet.org. [21] Los feeds privados se pueden mantener 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 medio para compilar programas de Visual C++ para ejecutarlos dentro de .NET Framework. Algunas partes del programa C++ aún se ejecutan dentro de un tiempo de ejecución de Visual C++ no administrado , mientras que las partes especialmente modificadas se traducen a código CIL y se ejecutan con CLR de .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. [22] Estos ensamblados son más complejos de aplicar ingeniería inversa ya que los descompiladores de .NET como .NET Reflector revelan solo el código administrado.
Debido a que los sistemas informáticos comúnmente requieren interacción entre aplicaciones más nuevas y más antiguas, .NET Framework proporciona medios para acceder a funciones implementadas en programas más nuevos y más 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 marco. El acceso a otras funciones se realiza a través de Platform Invocation Services (P/Invoke). El acceso a las funciones .NET desde aplicaciones nativas se realiza a través de la función P/Invoke inversa.
.NET Framework presenta un sistema de tipos comunes (CTS) que define todos los tipos de datos y construcciones de programación posibles admitidos por CLR y cómo pueden o no interactuar de acuerdo con las especificaciones CLI. Debido a esta característica, .NET Framework admite el intercambio de tipos e instancias de objetos entre bibliotecas y aplicaciones escritas utilizando cualquier lenguaje CLI compatible .
CTS y CLR utilizados en .NET Framework también imponen la seguridad de tipos . Esto evita conversiones mal definidas, invocaciones de métodos incorrectos y problemas de tamaño de memoria al acceder a un objeto. Esto también hace que la mayoría de los lenguajes CLI sean de tipo estático (con o sin inferencia de tipos ). Sin embargo, a partir de .NET Framework 4.0, Dynamic Language Runtime amplió el CLR, lo que permitió implementar lenguajes escritos dinámicamente encima de la CLI.
Si bien Microsoft nunca ha implementado el marco completo en ningún sistema excepto Microsoft Windows, ha diseñado el marco para que sea multiplataforma [23] y hay implementaciones disponibles para otros sistemas operativos (consulte Silverlight y § Implementaciones alternativas). Microsoft envió las especificaciones para CLI (que incluye las bibliotecas de clase base, CTS y CIL), [24] [25] [26] C# , [5] y C++/CLI [27] tanto a Ecma International (ECMA) como a International Organización de Normalización (ISO), poniéndolos a disposición como normas oficiales. Esto hace posible que terceros creen implementaciones compatibles del marco y sus lenguajes en otras plataformas.
Core multiplataforma .NET (anteriormente .NET Core) también está disponible oficialmente para muchas distribuciones de Linux y MacOS. [28]
.NET Framework tiene su propio mecanismo de seguridad con dos características generales: Seguridad de acceso al código (CAS) y validación y verificación. CAS se basa en evidencia asociada con un ensamblaje específico. Normalmente, la evidencia es la fuente del ensamblaje (ya sea que esté instalado en la máquina local o se haya descargado de Internet). CAS utiliza evidencia para determinar los permisos otorgados al código. Cuando el código de llamada exige que se le otorgue un permiso específico, CLR realiza un recorrido de la pila de llamadas verificando cada ensamblaje de cada método en la pila de llamadas para obtener el permiso requerido; Si a algún ensamblado no se le concede el permiso, se generará una excepción de seguridad.
El código de bytes CIL administrado es más fácil de aplicar ingeniería inversa que el código nativo, a menos que esté ofuscado . [29] Los programas descompiladores de .NET permiten a los desarrolladores sin conocimientos de ingeniería inversa ver el código fuente detrás de ensamblados .NET sin ofuscar. Por el contrario, las aplicaciones compiladas en código de máquina nativo son mucho más difíciles de aplicar mediante 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 . [30] Esto genera preocupación en la comunidad empresarial por 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 . Las herramientas de cifrado a nivel de método para código .NET están disponibles a través de proveedores como SafeNet .
CLR libera al desarrollador de la carga de administrar la memoria (asignar y liberar cuando termina); se encarga de la gestión de la memoria detectando cuándo se puede liberar la memoria de forma segura. Las instancias de tipos (objetos) .NET se asignan desde el montón administrado; un grupo de memoria administrado por CLR. Mientras exista una referencia a un objeto, que puede ser directa o mediante un gráfico 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, elegible para su recolección.
.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 y 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 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étodos actualmente dentro del alcance y objetos a los que hacen referencia los registros de la CPU. [31] Cuando se ejecuta GC, pausa la aplicación y luego, para cada objeto al que se hace referencia en la raíz, enumera recursivamente todos los objetos accesibles desde los objetos raíz y los marca como accesibles. Utiliza metadatos CLI y reflexión para descubrir los objetos encapsulados por un objeto y luego recorrerlos de forma recursiva. Luego enumera todos los objetos en el montón (que inicialmente se asignaron de forma contigua) mediante la reflexión. Todos los objetos no marcados como accesibles son basura. [31] Esta es la fase de marca . [32] Dado que la memoria contenida en la basura no tiene importancia, se considera espacio libre. Sin embargo, esto deja espacios libres 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. [31] [32] GC actualiza cualquier referencia a un objeto invalidada al mover el objeto para reflejar la nueva ubicación. [32] La aplicación se reanuda una vez finalizada la recolección de basura. La última versión de .NET Framework utiliza recolección de basura simultánea junto con el código de usuario, lo que hace que las pausas sean imperceptibles porque se realiza en segundo plano. [33]
El recolector de basura utilizado por .NET Framework también es generacional . [34] A los objetos se les asigna una generación . Los objetos recién creados están etiquetados 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 colección son de Generación 2 . El marco utiliza hasta objetos de Generación 2. [34] Los objetos de mayor generación se recolectan como basura con menos frecuencia que los objetos de menor generación. 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. [34] 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. [34]
Cuando se inicia una aplicación por primera vez, .NET Framework compila el código CIL en código ejecutable utilizando su compilador justo a tiempo y almacena en caché el programa ejecutable en .NET Native Image Cache. [35] [36] Debido 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 utilizar la utilidad Native Image Generator para compilar y almacenar en caché manualmente con anticipación cualquier aplicación .NET. [36]
El recolector de basura, que está integrado en el entorno, puede introducir retrasos de ejecución imprevistos sobre los cuales 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 visitarlos y reorganizarlos todos". [37]
.NET Framework brinda soporte para llamar a Streaming SIMD Extensions (SSE) a través de código administrado desde abril de 2014 en Visual Studio 2013 Update 2. Sin embargo, Mono ha brindado soporte para Extensiones SIMD a partir de la versión 2.2 dentro del espacio de nombres Mono.Simd en 2009. [38 ] 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. [39] Las extensiones SIMD de transmisión han estado disponibles en 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 soporte estas extensiones, las instrucciones se simulan en el software. [40] [41]
.NET Framework fue la implementación predominante de CLI, hasta el lanzamiento de .NET . Existen otras implementaciones para partes del marco. Aunque el motor de tiempo de ejecución se describe mediante una especificación ECMA-ISO, otras implementaciones del mismo pueden verse obstaculizadas por cuestiones de patentes ; Las normas ISO pueden incluir la exención de responsabilidad: "Se llama la atención sobre la posibilidad de que algunos de los elementos de este documento puedan estar sujetos a derechos de patente. ISO no será responsable de identificar ninguno o todos esos derechos de patente". [42] Es más difícil desarrollar alternativas al FCL, que no está descrito en un estándar abierto y puede estar sujeto a restricciones de derechos de autor. Además, algunas partes de FCL tienen funciones y comportamientos específicos de Windows, por lo que la implementación en plataformas que no sean Windows puede resultar problemática.
Aquí se enumeran algunas implementaciones alternativas de partes del marco.
Los marcos de código administrado de Microsoft y sus componentes tienen las siguientes licencias:
Sin embargo, hay varias bibliotecas incluidas con Mono y comúnmente utilizadas por aplicaciones como Tomboy, que no son requeridas por el estándar.
Y para que quede claro, no estamos hablando de bibliotecas específicas de Windows como ASP.NET y Windows Forms.
En cambio, estamos hablando de bibliotecas bajo el espacio de nombres System que brindan la funcionalidad común que los programadores esperan en los lenguajes de programación modernos.
