.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 reemplazado 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 (en contraste con un entorno de hardware ) llamado Common Language Runtime (CLR). El 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 de computadora escrito con .NET Framework se llama " código administrado ". FCL y CLR juntos constituyen .NET Framework.
FCL proporciona la interfaz de usuario , el acceso a los datos , la conectividad de bases de datos , la criptografía , el desarrollo de aplicaciones web , los algoritmos numéricos y las comunicaciones en red . Los programadores producen software combinando su código fuente con .NET Framework y otras bibliotecas. El marco está pensado para que lo utilicen la mayoría de las nuevas aplicaciones 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 inmediatamente, 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 con respecto 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 un proyecto de software desarrollado por la comunidad, incluida la publicación de una actualización de su patente prometiendo abordar las preocupaciones. [2]
En abril de 2019, Microsoft lanzó .NET Framework 4.8, la última versión principal del marco como oferta propia, 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 se planean más cambios para esa versión. .NET Framework seguirá estando incluido en futuras versiones de Windows y seguirá recibiendo actualizaciones de seguridad, sin planes de eliminarlo a partir de septiembre de 2024. [3]
Microsoft comenzó a desarrollar .NET Framework a finales de los años 90, 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 fueron ratificados por las normas ECMA . [4] [5] La Organización Internacional de Normalización (ISO) siguió su ejemplo en abril de 2003. Las versiones actuales de las normas ISO son ISO/IEC 23271:2012 e ISO/IEC 23270:2006. [6] [7]
Aunque Microsoft y sus socios poseen patentes para CLI y C#, ECMA e ISO exigen que todas las patentes esenciales para la implementación se pongan a disposición en " términos razonables y no discriminatorios ". Las empresas acordaron cumplir estos términos y poner a disposición las patentes sin pagar regalías. Sin embargo, esto no se aplicó a la parte de .NET Framework no cubierta por los estándares ECMA-ISO, que incluía Windows Forms , ADO.NET y ASP.NET . Las patentes que Microsoft posee en estas áreas pueden haber disuadido a terceros de implementar el marco completo. [8]
Windows Vista es la primera versión cliente de Windows que integró .NET Framework.
El 3 de octubre de 2007, Microsoft anunció que el código fuente de las bibliotecas de .NET Framework 3.5 iba a estar disponible bajo la licencia Microsoft Reference Source License (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 iban a añadir las bibliotecas LINQ, WCF y WF. [10]
Las variantes .NET Compact Framework y .NET Micro Framework de .NET Framework ofrecían compatibilidad con otras plataformas de Microsoft, como Windows Mobile , Windows CE y otros dispositivos integrados con recursos limitados. Silverlight ofrecía compatibilidad con 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. Los proyectos anteriores como Mono existían en una zona gris legal porque las concesiones anteriores de Microsoft se aplicaban solo a la tecnología en "especificaciones cubiertas", incluidas estrictamente las 4.ª ediciones de ECMA-334 y ECMA-335. Sin embargo, la nueva promesa de patente no impone ningún límite a la versión de la 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 implementarla. Esto permite que Mono y otros proyectos mantengan la paridad de características con las características .NET modernas que se han introducido desde que se publicó la 4.ª edición sin correr el riesgo de litigios de patentes sobre la implementación de esas características. 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 licenciar Mono por completo bajo una licencia MIT incluso en escenarios en los que anteriormente se necesitaba una licencia comercial. [12] Microsoft también complementó su promesa de patente anterior para Mono, declarando que no harán valer ninguna "patente aplicable" contra las partes que "estén usando, vendiendo, ofreciendo para la venta, importando o distribuyendo Mono". [13] [14] Se anunció que el Proyecto Mono fue aportado 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 totalmente de código abierto. Microsoft publicó el código fuente de WPF, Windows Forms y WinUI el 4 de diciembre de 2018. [16]
Common Language Infrastructure (CLI) ofrece una plataforma independiente del lenguaje para el desarrollo y la ejecución de aplicaciones. Al implementar los aspectos básicos de .NET Framework dentro del alcance de CLI, estas funciones no estarán vinculadas a un solo lenguaje, sino que estarán disponibles en todos los lenguajes compatibles con el marco.
.NET Framework incluye Common Language Runtime (CLR). Funciona 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 elementos no utilizados , 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 ensambles CLI . Tal como lo exige la especificación, los ensambles se almacenan en formato de archivo Portable Executable (PE), común en la plataforma Windows para todos los archivos EXE ejecutables y de biblioteca de vínculos dinámicos (DLL) . Cada ensamble consta de uno o más archivos, uno de los cuales debe contener un manifiesto con los metadatos del ensamble. El nombre completo de un ensamble (que no debe confundirse con el nombre del archivo en el disco) contiene su nombre de texto simple, número de versión, cultura y token de clave pública . Los ensambles se consideran equivalentes si comparten el mismo nombre completo.
El creador del ensamblaje también puede utilizar una clave privada para asignarle un nombre seguro . El token de clave pública determina la identidad real del firmante del ensamblaje. Solo aquellos que conocen su clave privada (del sistema de criptografía de doble clave) pueden firmar ensamblajes que tengan el mismo nombre seguro que un ensamblaje de una versión anterior. Se requiere un nombre seguro para agregar ensamblajes a la caché de ensamblajes 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 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 uno System.*o más Microsoft.*espacios de nombres. Estas bibliotecas de clases implementan muchas funciones comunes, como lectura y escritura de archivos, representación gráfica, interacción con bases de datos y manipulación de documentos XML. Las bibliotecas de clases están disponibles para todos los lenguajes compatibles con CLI . La FCL implementa la biblioteca de clases base (BCL) de CLI y otras bibliotecas de clases, algunas de las cuales 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 central de clases que sirven como API básica de CLR. [18] Para .NET Framework, la mayoría de las clases consideradas como parte de BCL residen en mscorlib.dll, System.dlly System.Core.dll. Las clases 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 .
FCL hace referencia a toda la biblioteca de clases que se incluye con .NET Framework. Incluye BCL, un conjunto ampliado de bibliotecas, entre las que se incluyen 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 alternativas de CLI (por ejemplo, Silverlight), Microsoft introdujo el concepto de bibliotecas de clases portátiles (PCL), que permiten que una biblioteca de uso 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, se creó la biblioteca estándar .NET de forma retroactiva basándose en las System.Runtime.dllAPI basadas en UWP y Silverlight. Se anima a las nuevas implementaciones de CLI a implementar 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] Las fuentes privadas 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 que se ejecuten dentro de .NET Framework. Algunas partes del programa C++ aún se ejecutan dentro de un entorno de ejecución de Visual C++ no administrado , mientras que las partes especialmente modificadas se traducen a código CIL y se ejecutan con el CLR de .NET Framework .
Los ensamblajes compilados con el compilador C++/CLI se denominan ensamblajes de modo mixto, ya que contienen código nativo y administrado en la misma DLL. [22] Estos ensamblajes son más complejos de aplicar ingeniería inversa, ya que los descompiladores .NET como .NET Reflector revelan solo el código administrado.
Debido a que los sistemas informáticos suelen requerir la interacción entre aplicaciones nuevas y antiguas, .NET Framework proporciona medios para acceder a 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 marco. El acceso a otras funciones se realiza a través de los Servicios de invocación de plataforma (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 compatibles con CLR y cómo pueden o no interactuar de acuerdo con las especificaciones de CLI. Debido a esta característica, .NET Framework admite el intercambio de tipos e instancias de objetos entre bibliotecas y aplicaciones escritas con cualquier lenguaje CLI compatible .
CTS y el CLR que se utilizan en .NET Framework también aplican la seguridad de tipos . Esto evita conversiones mal definidas, invocaciones de métodos incorrectas y problemas de tamaño de memoria al acceder a un objeto. Esto también hace que la mayoría de los lenguajes de la CLI sean de tipo estático (con o sin inferencia de tipos ). Sin embargo, a partir de .NET Framework 4.0, Dynamic Language Runtime extendió el CLR, lo que permitió que los lenguajes de tipo dinámico se implementaran sobre la CLI.
Aunque 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 clases base, CTS y CIL), [24] [25] [26] C# , [5] y C++/CLI [27] tanto a Ecma International (ECMA) como a la Organización Internacional de Normalización (ISO), poniéndolas a disposición como estándares oficiales. Esto hace posible que terceros creen implementaciones compatibles del marco y sus lenguajes en otras plataformas.
El núcleo multiplataforma .NET (anteriormente .NET Core) está oficialmente disponible también para muchas distribuciones de Linux y MacOS. [28]
.NET Framework tiene su propio mecanismo de seguridad con dos características generales: Code Access Security (CAS) y validación y verificación. CAS se basa en evidencias asociadas a un ensamblado específico. Normalmente, las evidencias son la fuente del ensamblado (ya sea que esté instalado en la máquina local o se haya descargado de Internet). CAS utiliza evidencias para determinar los permisos otorgados al código. Cuando el código de llamada exige que se le conceda un permiso específico, CLR realiza un recorrido por la pila de llamadas para comprobar cada ensamblado de cada método en la pila de llamadas en busca del permiso requerido; si a algún ensamblado no se le concede 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 . [29] Los programas de descompilación de .NET permiten a los desarrolladores sin habilidades de ingeniería inversa ver el código fuente detrás de los ensamblajes .NET no ofuscados. Por el contrario, las aplicaciones compiladas en código de 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 . [30] 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] Las herramientas de ofuscación de terceros también están 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 de proveedores como SafeNet .
CLR libera al desarrollador de la carga de administrar la memoria (asignar y liberar cuando se termina); maneja la administración de memoria por sí mismo al detectar cuándo se puede liberar memoria de manera 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, que puede ser directa o a través de un gráfico de objetos, el objeto se considera en uso. Cuando no existe ninguna referencia a un objeto y no se puede acceder a él ni usarlo, 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 establecida 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 son no 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 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 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 de forma contigua) mediante reflexión. Todos los objetos que no están marcados como alcanzables son basura. [31] Esta es la fase de marcado . [32] Dado que la memoria que contiene la basura no tiene importancia, se considera espacio libre. Sin embargo, esto deja trozos de espacio libre entre los 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] Cualquier referencia a un objeto invalidada al mover el objeto es actualizada por GC para reflejar la nueva ubicación. [32] La aplicación se reanuda después de que finaliza la recolección de basura. La última versión de .NET framework utiliza la 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 que utiliza .NET Framework también es generacional . [34] 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 marco utiliza hasta objetos de Generación 2. [34] 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. [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 just-in-time 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 para 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é de forma manual y anticipada cualquier aplicación .NET. [36]
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 visitarlos y reorganizarlos todos". [37]
.NET Framework proporciona 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 proporcionado soporte para SIMD Extensions 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 Streaming SIMD Extensions han estado disponibles 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 carezca de soporte para esas 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 está descrito por una especificación ECMA-ISO, otras implementaciones del mismo pueden verse obstaculizadas por problemas 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 alguno o todos esos derechos de patente". [42] Es más difícil desarrollar alternativas a FCL, que no está descrito por un estándar abierto y puede estar sujeto a restricciones de derechos de autor. Además, partes de FCL tienen funciones y comportamiento específicos de Windows, por lo que la implementación en plataformas que no sean Windows puede ser problemática.
Aquí se enumeran algunas implementaciones alternativas de partes del marco.
Los marcos de código administrado de Microsoft y sus componentes tienen la siguiente licencia:
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 proporcionan la funcionalidad común que los programadores esperan en los lenguajes de programación modernos.
