Artículo principal: .

NET Framework historial de versiones

Microsoft comenzó el desarrollo de .NET Framework a finales de 1990, originalmente bajo el

nombre de la próxima generación de servicios de Windows (NGWS). A finales de 2000, las
primeras versiones beta de .NET 1.0 fueron puestos en libertad.

En agosto de 2000, Microsoft, Hewlett-Packard, y Intel trabajó para estandarizar

Infraestructura del lenguaje común (CLI) y la C #. En diciembre de 2001, ambos fueron
ratificados ECMA normas. [1] [2] ISO siguió en abril de 2003. La versión actual de las normas
ISO son la norma ISO / IEC 23271: 2012 e ISO / IEC 23270:. 2006 [3] [4]

Mientras que Microsoft y sus socios tienen patentes de CLI y C #, ECMA e ISO requieren que
todas las patentes esenciales para la implementación se efectuará en el "términos razonables y
no discriminatorios". Además de cumplir con estos términos, las compañías han acordado
hacer las patentes disponibles, libre de regalías. Sin embargo, esto no se aplica para la parte de
.NET Framework no comprendidas en las normas ECMA / ISO, que incluyeron Windows Forms,
ADO.NET y ASP.NET. Las patentes que Microsoft tiene en estas áreas pueden haber disuadido
a las implementaciones no son de Microsoft del marco completo. [5]

El 3 de octubre de 2007, Microsoft anunció que el código fuente para .NET Framework 3.5
bibliotecas se convertiría disponible bajo la Licencia Microsoft Referencia (Ms-RSL [a]). [6] El
repositorio de código fuente estaba disponible en línea el 16 de enero de 2008 y incluido BCL,
ASP.NET, ADO.NET, Windows Forms, WPF y XML. Scott Guthrie de Microsoft prometió LINQ,
bibliotecas WCF y WF estaban en proceso de ser añadido. [7]

El 12 de noviembre de 2014, Microsoft anunció .NET Core, en un esfuerzo para incluir soporte
multiplataforma para .NET, la liberación fuente de la implementación de Microsoft CoreCLR,
fuente para el "todo [...] pila biblioteca" para .NET Core, y la adopción de un ("bazar" -como)
convencional modelo de desarrollo de código abierto bajo la dirección del .NET Fundación.
Miguel de Icaza describe .NET Core como una "versión rediseñada de .NET que se basa en la
versión simplificada de la bibliotecas de clases ", [8] y Immo Landwerth de Microsoft explicó
que .NET Core sería" el fundamento de todas las futuras plataformas .NET ". En el momento
del anuncio, la versión inicial del proyecto .NET Core había sido sembrado con un subconjunto
de código fuente de las bibliotecas y coincidió con la renovación de licencias de fuente de
referencia de Microsoft .NET existente fuera de las restricciones de la Ms-RSL. Landwerth
reconoció las desventajas de la licencia de código compartido previamente seleccionado,
explicando que se hizo nombre en clave del rotor ", un non-starter" como un proyecto de
código abierto desarrollado por la comunidad, ya que no cumplía con los criterios de un OSI
licencia con aprobación para. [9] [ 10] [11]
Microsoft también produjo una actualización de sus concesiones de patentes, que se extiende
aún más el alcance más allá de sus compromisos anteriores. Proyectos anteriores como Mono
existían en un legal zona gris porque subvenciones anteriores de Microsoft aplicarán
únicamente a la tecnología en "especificaciones cubiertos", incluyendo estrictamente las 4tas
ediciones cada uno de ECMA-334 y ECMA-335. La nueva promesa de la patente, sin embargo,
no pone límite a la versión de especificación y se extiende incluso a las tecnologías de tiempo
de ejecución de .NET documentados en MSDN que no han sido especificados formalmente por
el grupo ECMA, si un proyecto opta por ponerlas en práctica. Esto permite Mono y otros
proyectos para mantener la paridad de características con las características modernas de .NET
que se han introducido desde la cuarta edición fue publicada sin estar en riesgo de litigios
sobre patentes sobre la aplicación de esas características. La nueva subvención hace mantener
la restricción de que ninguna aplicación debe mantener el cumplimiento mínimo de las partes
obligatorias de la especificación CLI. [12]

Comunicado de prensa de Microsoft destaca que el compromiso multiplataforma permite

ahora una fuente totalmente abierta, pila .NET en el servidor actual. Sin embargo, Microsoft no
tiene planes para liberar la fuente de WPF o formularios Windows Forms. [13] [14]

Versiones [editar]

Descripción general de la historia de la liberación de .NET Framework [15] [16]

Versión

número CLR

versión Lanzamiento

fecha Herramienta de desarrollo Incluido Reemplaza

Ventanas Windows Server

1.0 1.0 02/13/2002 Visual Studio .NET [17] XP [a] N / A N/A

1.1 1.1 04/24/2003 Visual Studio .NET 2003 [17] N/A 2003 1.0 [18]

2.0 2.0 2005-11-07 Visual Studio 2005 [19] N / A 2003, 2003 R2, [20] 2008 SP2,
2008 R2 SP1 N/A

3.0 2.0 2006-11-06 Expression Blend [21] [b] Vista 2008 SP2, 2008 R2 SP1
2.0 [15]

3.5 2.0 11/19/2007 Visual Studio 2008 [22] 7, 8 [c], 8.1 [c], 10 [c] 2008 R2 SP1
2.0, 3.0 [15]

4.0 4 04/12/2010 Visual Studio 2010 [23] N / A N/A N/A

4.5 4 08/15/2012 Visual 2012 Estudio [24] 8 2012 4.0 [15]

4.5.1 4 10/17/2013 Visual Studio 2013 [25] 8.1 2012 R2 4.0, 4.5 [15]

4.5.2 4 5.5.2014 N/A N/A N/A 4.0, 4.5, 4.5.1 [15]

4.6 4 07/20/2015 Visual Studio 2015 [26] 10 2016 4.0, 4.5, 4.5.1, 4.5.2

Notas:

a. ^ .NET Framework 1.0 es un componente integral de la edición del sistema operativo

Windows XP Media Center o edición de Tablet PC. CDs de instalación para las ediciones Home
y las ediciones Professional de Windows XP SP1, SP2 o SP3 viene con paquetes de instalación
de .NET Framework. [16]

b. ^ Expression Blend sólo cubre la Windows Presentation Foundation parte de .NET

Framework 3.0.

c. ^ ^ ^ .NET Framework 3.5 no se instala automáticamente con Windows 8, 8.1 o 10. Debe
instalarse ya sea desde un disco de instalación de Windows o desde el Internet bajo demanda.
Panel de control siempre intenta la segunda. [27]

vista hablar editar

Arquitectura [editar]

Resumen visual del Common Language Infrastructure (CLI)

Common Language Infrastructure [editar]

Artículo principal: Common Language Infrastructure

Common Language Infrastructure (CLI) proporciona una plataforma independiente del idioma
para el desarrollo y ejecución de la aplicación, incluyendo funciones para el manejo de
excepciones, recolección de basura, la seguridad y la interoperabilidad. Mediante la
implementación de los aspectos centrales de .NET Framework en el ámbito de la CLI, esta
funcionalidad no estará atado a un solo idioma, pero estará disponible a través de los muchos
idiomas admitidos por el marco. Implementación de Microsoft de CLI es Common Language
Runtime (CLR). Sirve como el motor de ejecución de .NET Framework. Todos los programas
.NET ejecutan bajo la supervisión de CLR, garantizar determinadas propiedades y
comportamientos en las áreas de gestión de la memoria, la seguridad y el manejo de
excepciones.

Para los programas informáticos se ejecuten en la CLI, que necesitan para ser compilado en
Common Intermediate Language (CIL) - en lugar de ser compilado en código máquina. Tras la
ejecución, una arquitectura específica compilador Just-in-time (JIT) convierte el código CIL en
código máquina. Para mejorar el rendimiento, sin embargo, .NET Framework viene con
Generador de imágenes nativas (NGEN) que realiza la compilación antes de tiempo.

Biblioteca de clases [editar]

.NET Framework incluye un conjunto de estándares bibliotecas de clases. La biblioteca de

clases se organizan en una jerarquía de espacios de nombres. La mayoría de las API
incorporadas son parte de cualquiera System.* O Microsoft.* Espacios de nombres. Estas
bibliotecas de clases implementan un gran número de funciones comunes, como la lectura de
archivos y la escritura, representación gráfica, la interacción de base de datos, y el documento
XML manipulación, entre otros. Bibliotecas de clases de .NET están disponibles para todos los
idiomas compatibles con la CLI. .NET Framework biblioteca de clases se divide en dos partes:
Marco de la biblioteca de clases (FCL) y Base Class Library (BCL).

FCL incluye un pequeño subconjunto de toda la biblioteca de clases y es el conjunto básico de

clases que sirven de base API del CLR. [28] Las clases en mscorlib.dll y algunas clases en
System.dll y System.core.dll son parte de FCL. Clases FCL están disponibles en .NET Framework,
así como sus implementaciones alternativas incluyendo .NET Compact Framework, Microsoft
Silverlight y Mono.

BCL es un superconjunto de FCL y hace referencia a la biblioteca de la clase entera que se

incluye con .NET Framework. Incluye un conjunto ampliado de las bibliotecas, incluyendo
Windows Forms, ADO.NET, ASP.NET, Language Integrated Query (LINQ), Windows
Presentation Foundation (WPF), Windows Communication Foundation (WCF) y Workflow
Foundation (WF). BCL es mucho mayor alcance que las bibliotecas estándar para lenguajes
como C ++, y comparable en alcance a las bibliotecas estándar de Java.

.NET Core [editar]

.NET Core es una libre y de código abierto aplicación multiplataforma de .NET Framework.
Consiste en CoreCLR una implementación completa de tiempo de ejecución multiplataforma
de CLR, la máquina virtual que gestiona la ejecución de programas .NET. .Net Core también
incluye CoreFX, que es un parcial tenedor de BCL y apoyará ASP.NET. [29] CoreCLR viene con
un mejorado compilador Just-in-time, llamado RyuJIT. [30] Red Core será capaz de ejecutar la
consola y aplicaciones ASP.NET en Windows, Linux, BSD y Mac OSX. Sin embargo, no
implementa Windows Forms o WPF que son esenciales para las aplicaciones de escritorio GUI
basada.

Asambleas [editar]

Código CIL Compilado se almacena en las asambleas de la CLI. Conforme a lo dispuesto por la
especificación, las asambleas se almacenan en ejecutable portable (PE) formato de archivo,
común en la plataforma de Windows para todos DLL y EXE archivos. Cada conjunto se
compone de uno o varios archivos, uno de los cuales debe contener un manifiesto que lleva el
metadatos para el montaje. El nombre completo de un conjunto (que no debe confundirse con
el nombre del archivo en el disco) contiene su nombre simple texto, número de versión, la
cultura, y la clave pública token. Asambleas se consideran equivalentes si comparten el mismo
nombre completo, excluyendo la revisión del número de versión.
Una clave privada también puede ser utilizado por el creador de la asamblea para el fuerte de
nomenclatura. El símbolo de clave pública identifica qué clave privada una asamblea se firmó
con. Sólo el creador del par de claves (típicamente desarrollador .NET firmar el montaje) puede
firmar asambleas que tienen el mismo nombre seguro como un conjunto versión anterior, ya
que el creador está en posesión de la clave privada. Se requiere Fuerte nombramiento añadir
asambleas para caché de ensamblados global.

C ++ / CLI [editar]

Artículo principal: C ++ / CLI

Microsoft introdujo C ++ / CLI en Visual Studio 2005, que es un lenguaje y medio de la

compilación de Visual C ++ programas para ejecutarse en el .NET Framework. Ciertas partes del
programa C ++ todavía funcionan dentro de un administrado C Runtime Visual ++, mientras
que las porciones especialmente modificados se traducen a código CIL y correr con el .NET
Framework CLR.

Asambleas compilados con el compilador C ++ / CLI se conocen como conjuntos de modo

mixto, ya que contienen nativo y código administrado dentro del mismo archivo DLL. [31] Tales
conjuntos también son difíciles de realizar ingeniería inversa, ya descompiladores .NET tales
como .NET Reflector única revelar el código administrado.

Principios de diseño [editar]

Interoperabilidad [editar]

Debido a que los sistemas informáticos comúnmente requieren la interacción entre las
aplicaciones más recientes y de mayor edad, .NET Framework proporciona medios para
acceder a la funcionalidad implementada en los programas más nuevos y más antiguos que se
ejecutan entorno .NET exterior. El acceso a COM componentes se proporciona en
System.Runtime.InteropServices y System.EnterpriseServices espacios de nombres del marco.
El acceso a otras funciones se logra mediante el / Invoke P característica.

La independencia de idioma [editar]

.NET Framework introduce un sistema de tipos común (CTS) que define todos los posibles tipos
de datos y programación construcciones apoyadas por CLR y la forma en que pueden o no
pueden interactuar entre sí conforme a la especificación CLI. Debido a esta característica, .NET
Framework apoya el intercambio de tipos e instancias de objetos entre las bibliotecas y
aplicaciones escritas utilizando cualquier lenguaje .NET conforme.

Portabilidad [editar]

Mientras que Microsoft nunca ha implementado el marco completo en cualquier sistema

excepto Microsoft Windows, se ha diseñado el marco para ser independiente de la plataforma,
[32] y las implementaciones entre plataformas están disponibles para otros sistemas
operativos (ver Silverlight y § implementaciones alternativas). Microsoft presentó las
especificaciones para la CLI (que incluye las bibliotecas de clases base, CTS y CIL), [33] [34] [35]
C #, [36] y C ++ / CLI [37] tanto ECMA e ISO, poniéndolas a disposición como normas oficiales.
Esto hace posible que los terceros para crear implementaciones compatibles del marco y de
sus lenguas en otras plataformas.

Seguridad [editar]

.NET Framework tiene su propio mecanismo de seguridad con dos características generales:
Código de Acceso de Seguridad (CAS) y la validación y verificación. CAS se basa en pruebas que
se asocia con un conjunto específico. Por lo general la evidencia es la fuente de la asamblea (si
está instalado en el equipo local o se ha descargado desde la intranet o Internet). CAS utiliza
pruebas para determinar los permisos concedidos al código. Otro código puede exigir que
código de llamada se concederá un permiso especificado. La demanda hace que CLR para
realizar un paseo pila de llamadas: todas las asambleas de cada método en la pila de llamadas
está activada para el permiso necesario; si cualquier asamblea no se concede el permiso se
lanza una excepción de seguridad.

Gestionado CIL bytecode es más fácil de realizar ingeniería inversa de código nativo, a menos
ofuscado. [38] [39] NET Decompiler programas permiten a los desarrolladores sin necesidad de
conocimientos de ingeniería inversa para ver el código fuente detrás ensamblados .NET
unobfuscated. Por el contrario, las aplicaciones compilado a código máquina nativo son mucho
más difíciles de realizar 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. [Cita
requerida] Una preocupación es por la posible pérdida de secretos comerciales y la derivación
de los mecanismos de control de licencias. Para mitigar esto, Microsoft ha incluido Dotfuscator
Community Edition con Visual Studio .NET desde el año 2002. [b] herramientas de ofuscación
de terceros también están disponibles de proveedores como VMware, Vi laboratorios,
Xenocode, Red Gate Software. Herramientas de cifrado a nivel de método de código .NET
están disponibles de proveedores como SafeNet.

Gestión de la memoria [editar]

CLR libera al desarrollador de la carga de la gestión de memoria (asignación y liberación

cuando se hace); que maneja la propia gestión de memoria al detectar cuando la memoria se
puede liberar de forma segura. Instancias de tipos de .NET (objetos) se asignan desde el
montón administrado; una piscina de la memoria gestionado por CLR. Mientras existe una
referencia a un objeto, que puede ser o bien una referencia directa a un objeto o a través de
un gráfico de objetos, el objeto se considera que está en uso. Cuando no hay ninguna
referencia a un objeto, y no puede ser alcanzado o utilizada, se convierte en basura, elegibles
para la colección.
.NET Framework incluye un recolector de basura (GC), que ejecuta periódicamente, en un
aparte del hilo de rosca de la aplicación, que enumera todos los objetos inservibles y recupera
la memoria asignada a ellos. Es un, compactación, no determinista mark-and-sweep recolector
de basura. GC sólo se ejecuta cuando se ha utilizado una cierta cantidad de memoria o hay
suficiente presión para la memoria en el sistema. Dado que no se garantiza cuando se alcanzan
las condiciones para recuperar la memoria, GC carreras son no determinista. Cada
aplicación .NET tiene un conjunto de raíces, que son punteros a objetos en el montón
administrado (objetos gestionados). Estos incluyen referencias a objetos estáticos y objetos
definidos como variables o parámetros del método actualmente en el ámbito local, así como
los objetos mencionados por registros de la CPU. [40] Cuando GC se ejecuta, se detiene la
aplicación, y para cada objeto que se refiere en la raíz , que de forma recursiva enumera todos
los objetos alcanzables de los objetos de la raíz y los marca como alcanzable. Utiliza CLI
metadatos y la reflexión para descubrir los objetos encapsulados por un objeto, y luego
caminar ellos de forma recursiva. A continuación, se enumeran todos los objetos en el montón
(que se asignó inicialmente contigua) con la reflexión. Todos los objetos no marcados como
accesibles son basura. [40] Esta es la fase de la marca. [41] Desde la memoria en poder de
basura no es de ninguna consecuencia, se considera espacio libre. Sin embargo, esto deja
trozos de espacio libre entre los objetos que eran inicialmente contigua. Los objetos son luego
compactan juntos para hacer contigua de memoria utilizada. [40] [41] Cualquier referencia a
un objeto invalidado moviendo el objeto se actualiza mediante GC para reflejar la nueva
ubicación. [41] La aplicación se reanuda después de la recolección de basura se acabó. La
última versión del marco .NET utiliza la recogida de basura simultánea junto con el código de
usuario, toma una pausa imperceptible desde su hacer en el fondo. [42]

GC utilizado por .NET Framework también es generacional. [43] Los objetos se asignan a una
generación; objetos recién creados pertenecen a la Generación 0. Los objetos que sobreviven a
una recolección de basura etiquetados como Generación 1, y los objetos Generación 1 que
sobreviven otra colección son Generación 2 objetos. .NET Framework utiliza hasta Generación
2 objetos. [43] los objetos más altos generación son basura recogida con menos frecuencia que
los objetos más bajos generación. Esto ayuda a aumentar la eficiencia de recolección de
basura, como objetos mayores tienden a tener una vida útil más larga que los objetos más
nuevos. [43] Por lo tanto, mediante la eliminación de más edad (y por lo tanto más
probabilidades de sobrevivir una colección) Objetos del alcance de una ejecución de
obtención, menos objetos necesitan ser revisados y compactado. [43]

Despliegue simplificado [editar]

.NET Framework incluye características de diseño y herramientas que ayudan a gestionar la

instalación de software para asegurarse de que no interfiera con el software instalado
previamente, y que se ajusta a los requisitos de seguridad. [Cita requerida]

Rendimiento [editar]

Cuando se lanzó por primera vez una aplicación, el .NET Framework compila el código de CIL
en código ejecutable utilizando su compilador Just-in-time, y almacena en caché el programa
ejecutable en el .NET nativo caché de imágenes. [44] [45] Debido al almacenamiento en caché,
la aplicación se inicia más rápido para los lanzamientos posteriores, aunque el primer
lanzamiento es por lo general más lento. Para aumentar la velocidad de la primera puesta en
marcha, los desarrolladores pueden utilizar el Generador de imágenes nativas utilidad para
compilar manualmente y almacenar en caché cualquier aplicación .NET, por delante de los
tiempos. [45]

El recolector de basura, que está integrado en el medio ambiente, se puede introducir retrasos
imprevistos de ejecución sobre la que el desarrollador tiene poco control directo. "En grandes
aplicaciones, el número de objetos que el recolector de basura tiene que hacer frente a puede
llegar a ser muy grande, lo que significa que puede llevar mucho tiempo para visitar y
reorganizar todos ellos." [46]

.NET Framework proporciona soporte para llamar Streaming SIMD Extensions (SSE) a través de
código administrado a partir de abril de 2014 en Visual Studio 2013 Actualización 2. Sin
embargo, Mono ha prestado apoyo a SIMD Extensiones partir de la versión 2.2 en el espacio
de nombres Mono.Simd; antes de. Desarrollador principal de Mono Miguel de Icaza ha
expresado su esperanza de que este apoyo SIMD será adoptado por estándar ECMA del CLR.
[47] Streaming SIMD Extensions han estado disponibles en x86 CPU 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 carece de soporte para las extensiones, las instrucciones son simuladas
en el software. [Cita requerida]

Licencias [editar]

Componentes de .NET Framework tienen licencia de la siguiente manera:

Componente Licencia

.NET Core

CoreFX y CoreCLR MIT License [48]

.NET Micro Framework Apache License 2.0 [49]

.NET Plataforma Compiler (nombre en clave "Roslyn") Apache License 2.0 [50]

ASP.NET Apache License 2.0 [51]

Web Stack ASP.NET Apache License 2.0 [52]

Kit de herramientas de control de ASP.NET AjaxLicencia BSD [53]

ASP.NET SignalR Apache License 2.0 [54]

Entity Framework Apache License 2.0 [55]

NuGet Apache License 2.0 [56]

Referencia código fuente de .NET Framework 4.5 y anteriores Licencia Microsoft Referencia
(Ms-RSL [a]) [6] [57]

Referencia código fuente de .NET Framework 4.6 MIT License [58]

.NET Framework paquete redistribuible El software propietario [59]

Implementaciones alternativas [editar]

.NET Framework es la aplicación predominante de tecnologías .NET. Existen otras

implementaciones para partes del marco. Aunque el motor de tiempo de ejecución es descrito
por una especificación ECMA / ISO, otras implementaciones de la misma pueden ser gravados
por cuestiones de patentes; Normas ISO pueden incluir la exención de responsabilidad, "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 se hace responsable por la identificación de
cualquiera o todos los derechos de patente." [60] Es es más difícil de desarrollar alternativas a
FCL, que no está descrito por un estándar abierto y puede estar sujeto a restricciones de
copyright. Además, partes de FCL tienen funcionalidad específicas de Windows y la conducta,
por lo que la implementación en plataformas no Windows puede ser problemático.

Algunas implementaciones alternativas de partes del marco se enumeran aquí.

.NET Micro Framework es una plataforma .NET para dispositivos extremadamente limitados
recursos. Incluye una pequeña versión de CLR y apoya el desarrollo en C # (aunque algunos
desarrolladores fueron capaces de utilizar VB.NET, [61] aunque con una cantidad de piratería,
y con todas las funciones limitadas) y la depuración (en un emulador o en el hardware), tanto
utilizando Microsoft Visual Studio. También cuenta con un subconjunto de clases de .NET
Framework Biblioteca (cerca de 70 clases con cerca de 420 métodos), una interfaz gráfica de
usuario marco vagamente basada en WPF, y bibliotecas adicionales específicos para
aplicaciones embebidas.

Mono es una implementación de CLI y FCL, y proporciona funcionalidad adicional. Es de doble

licencia bajo software libre y software propietario licencias. Incluye soporte para ASP.NET,
ADO.NET y Windows Forms bibliotecas para una amplia gama de arquitecturas y sistemas
operativos. También incluye C # y VB.NET compiladores.

Portable.NET (parte de DotGNU) proporciona una implementación de CLI, porciones de FCL, y

un compilador de C #. Es compatible con una variedad de sistemas de CPU y de operación.

Microsoft Shared Source Common Language Infrastructure es un no-libre ejecución de CLR. Sin
embargo, la última versión sólo se ejecuta en Microsoft Windows XP SP2, y no ha sido
actualizado desde 2006, por lo que no contiene todas las características de la versión 2.0 de
.NET Framework.

Crossnet [62] es una implementación de CLI y porciones de FCL. Es software libre con el código
abierto licencia MIT.