Microsoft .Net CLR Common Language Runtimedi002.edv.uniovi.es/~benja/cs/presentaciones/4-CLR.pdf · Introducción. 2 Francisco Ortín Soler Junio 2002.net Framework ... Máquina-P

1

Universidad de Oviedo Departamento de Informática

Francisco Ortín SolerJunio, 2002

Microsoft .Microsoft .NetNetCLRCLR

((Common Language RuntimeCommon Language Runtime))

Francisco Ortín SolerJunio 2002

Necesidad de una InfraestructuraNecesidad de una Infraestructura

• El desarrollo de aplicaciones software es una tarea en sí compleja

• La apertura de éstas a entornos distribuidos (Internet) la hace todavía más compleja ⇒

Puede dar lugar al fracaso de un proyecto• Los requisitos de infraestructura de las

aplicaciones distribuidas son los mismos, ¿por qué no ofrecerlos en una plataforma?

• Microsoft .net es una plataforma que ofrece la infraestructura para resolver los problemas comunes del desarrollo de aplicaciones distribuidas

Introducción

2


..net Frameworknet Framework• .net Framework proporciona soluciones

prefabricadas para el desarrollo de aplicaciones distribuidas. Consta de:1. Common Language Runtime (CLR)

� Proporciona el entorno de ejecución de todas las aplicaciones del sistema

� Proporciona una capa intermedia entre el sistema operativo y las aplicaciones

� Su diseño se basa en el concepto de máquina virtual o abstracta

2. Librerías de clases: Base Class Libraries (BCL), WinForms, Win32, ADO.NET...

3. Plataforma de Aplicaciones Web: ASP.NET y Servicios Web

Introducción


CLRCLR

• La utilización del CLR aporta las siguientes ventajas:1. Disponibilidad de las características de cualquier

lenguaje: La elección del lenguaje estará condicionada por el dominio del problema, no por otras características –librerías, eficiencia, frameworks... ¿Puedo utilizar el API de Java desde otros lenguajes?

2. Heterogeneidad: Internet es una arquitectura heterogénea, las aplicaciones deberían poder ejecutarse de forma independiente a la plataforma

3. Interoperabilidad de aplicaciones orientadas a objetos, independientemente de los lenguajesde programación seleccionados

4. Gestión automática de memoria: la gestión de memoria es compleja en aplicaciones de servidor

Introducción

3


CLR (II)CLR (II)Introducción

5. El mantenimiento de aplicaciones da lugar a versiones de componentes OO utilizados por diversas aplicaciones. La coexistencia de distintas versiones de componentes demandada por distintos clientes debe ser gestionada sin incoherencias

6. Las aplicaciones distribuidas por redes son cada vez más un canal de adquisición y ejecución de software. La limitación de acceso a recursos por aplicaciones posee mayor veracidad que un sistema “todo o nada” de certificados

7. Organización de las funciones del sistemaoperativo mediante jerarquías

8. Debe mantenerse “compatibilidad hacia atrás” para crear e interactuar con código existente (legacy code)


Expresividad de los LenguajesExpresividad de los Lenguajes• Siempre puede aparecer la controversia acerca de

qué lenguaje de programación utilizar• Lo ideal es que la elección de un lenguaje estuviera

condicionada al dominio del problema (parcial o total) a resolver

• Las facetas propias de:� Librerías� Gestión de memoria� Eficiencia� Tamaño de los programas a utilizar� Componentes� Portabilidad� Distribución� Persistencia

estarán ligadas al entorno de ejecución (al CLR), no al lenguaje

Independencia del Lenguaje

4


Entorno Computacional ÚnicoEntorno Computacional ÚnicoIndependencia del Lenguaje

HaskellScript

Orientado a Objetos

Funcional/Lógico

Dinámico/Scripting

Estático

MLProlog

Haskell

C++VBS VBA VB.NET

C#Perl

Python

JScript

Procesamientodel Lenguaje

Paradigma

¡Todos se ejecutan sobre el mismo entorno de ejecución: el CLR!


SoluciónSoluciónIndependencia del Lenguaje

Pascal C#

JScriptVB Haskell

Oberon SchemePython MondrianCobol

EiffelSMLMercury

Más de 20 lenguajes

Compilación

Código Intermedio: IL (Intermediate Language), MSIL (Microsoft...), CIL (Common...)

CLR

Sistema Operativo

Ejecución

Objetivos Principales:• Ejecución de aplicaciones• Generación de código nativo (JIT)• Gestión de Memoria (GC)• Gestión de versiones (componentes)• Seguridad (acceso recursos)• Manejo de excepciones• Único Sistema de tipos• Independencia de la plataforma• Interoperabilidad con COM

5


DemoDemoIndependencia del Lenguaje

• ILASM (Intermediate Language Assembler):� Hola.il� Angulo.il


Independencia de la PlataformaIndependencia de la PlataformaHeterogeneidad

• Internet es heterogéneo• Una aplicación deberá ser capaz de ejecutarse en

cualquier plataforma –Windows o no.• Write one, run anywhere• La utilización de una plataforma virtual, permite que

una aplicación se ejecute en cualquier dispositivo capaz de ejecutar una implementación del CLR

• Muy útil para distribuir código por redes

6


Portabilidad de un LenguajePortabilidad de un Lenguaje• Máquina abstracta: Diseño de un procesador

computacional sin intención de que éste sea desarrollado de forma física

• La utilización de una plataforma intermedia abstracta (máquina virtual) ya fue utilizada en los 70 por la UCSD para construir código pascal portable (p-code)

• Posteriormente, se utilizó en Scheme, Prolog, Smalltalk y Java

Heterogeneidad

Pascal

Compilación

P-code

Máquina-P

Ejecución

Máquina-PMáquina-P Máquina-P

DEC LSIZilog Z80 Motorola 68000

Intel 8088


Distribución de CódigoDistribución de Código• Las aplicaciones podrán ejecutarse en todas las plataformas

que posean una implementación de la máquina abstracta• Se facilita la distribución de código por la red: En el caso

de Java, permitía ejecutar Applets en cualquier plataforma (navegador)

Heterogeneidad

Código Portable

Aplicación

Compilación

7


Portabilidad de un Único LenguajePortabilidad de un Único Lenguaje• La utilización de máquinas virtuales ha estado

enfocada a la portabilidad de un único lenguaje• “Lo mejor de la plataforma Java, sólo es

accesible desde el lenguaje Java”:� Modelo de componentes (JavaBeans)� Distribución (RMI, applets, java.net...)� Serialización� Gestión de memoria� Conjunto de librerías� Servidores de aplicaciones J2EE� ...

• La idea de Microsoft.net es que todas estas ventajas sean accesibles directamente (sin bridges) desde cualquier lenguaje

Heterogeneidad


CommonCommon Language RuntimeLanguage RuntimeHeterogeneidad

• El CLR fue diseñado para poder ejecutar un elevado número de lenguajes de programación (Common)

• ¿Es capaz de ejecutar cualquier lenguaje? Existen algún lenguaje (o características de algún lenguaje), que no puede computar de un modo directo:� Forth� El concepto de continuation de Scheme

VB HaskellEiffelC#

Compilación

CLR

Sistema Operativo

Ejecución

8


DemoDemoHeterogeneidad

• HolaVB.vb• HolaCS.cs• ILDASM (Intemediate Language Disassembler)• Comparación de código generado


EficienciaEficiencia• La utilización de un único motor computacional (CLR)

proporciona multitud de ventajas, pero un claro inconveniente: la eficiencia

• La interpretación es más cara que la ejecución nativa, puesto que existe un nivel computacional más

• ¿Es el CLR un intérprete? NO (necesariamente)• En lugar de interpretar el código, el CLR (Compilador JIT):

� Compila dinámicamente el código a su representación nativa en la plataforma de ejecución

� Optimiza el código generado (e.g., inlining)

Heterogeneidad

Código PortableAplicación

Compilación Ejecución

0110001Compilador JIT

9


Utilización del JIT Utilización del JIT

• La utilización de la compilación bajo demanda (JIT) es óptima para aplicaciones descargadas de una red� Se ejecutan de un modo esporádico� Su actualización es frecuente

• Sin embargo, la generación de código nativo, cada vez que se ejecuta una aplicación de escritorio, es una tarea inútil:

Conviene llevar en el sistema un almacén de imágenes nativas de las aplicaciones generadas

Heterogeneidad


DemoDemoHeterogeneidad

• JIT.cs• NGEN (Native Generator)• Compilación / Ejecución:

� Debug / sin imagen (ngen /delete)� No-debug / con imagen (ngen)

10


Interacción de AplicacionesInteracción de AplicacionesInteroperabilidad

• La utilización de una máquina virtual permite que las aplicaciones interactúen independientemente del lenguaje de programación empleado

• COM trataba de conseguir dicho objetivo, pero tiene los siguientes inconvenientes:� Es necesaria una elevada infraestructura para cada

componente: factorías de clases, contadores de referencias de interfaz, GUIDs, Progs IDs, necesidad o no de IDispatch...

� No se comparte una única implementación de un modelo computacional: la traducción de los distintos elementos es una tarea compleja� String(Pascal) != String(C++) != String(Java)

� La representación de los objetos es distinta para cada lenguaje

� ...


MetadatosMetadatosInteroperabilidad

• La interacción entre aplicaciones en .net es directa gracias a los metadatos (metadata): la representación de los datos es común en todos los lenguajes de programación

• Un archivo “.exe” en .net es portable (portable executable) puesto que consta de:� Código gestionado (managed code): Código

intermedio que será ejecutado por el CLR en cualquier plataforma

� Metadatos (metadata): Descripción de todas las estructuras de una aplicación (clases, atributos, métodos, signaturas...)

• De este modo, la interacción entre aplicaciones es directa, sin necesidad de traducciones previas

11


DemoDemoInteroperabilidad

• Modificar Holacs.cs para que invoque a HolaVB.Mostrar()

• Compilar Holavb.vb con /target:library• Compilar Holacs.cs con /r:holavb.dll

• Holacs.exe: Interacción directa de dos lenguajes de dos lenguajes de programación (VB y C#)


EnsambladosEnsambladosInteroperabilidad

• Un ensamblado (assembly) es una colección lógica de recursos de una aplicación (archivos “.exe”, “.dll”, “.ini”, “.jpg”...)

• Es una unidad reutilizable de implantación (despliegue); componente

• La generación de ensamblados puede llevarse a cabo mediante la utilización del Assembly Linker (AL.exe) del .net Framework

• Los ensamblados poseen un conjunto de módulos: código gestionado (archivos “.exe” y “.dll”)

12


MódulosMódulosInteroperabilidad

• Los ensamblados poseen un conjunto de módulos: código gestionado (archivos “.exe” y “.dll”)

• Los cada ensamblado ha de tener un módulo principal

• Los distintos módulosde un ensamblado interactúan entre sí mediante la utilización de sus metadatos:

Metadatos

CIL

Metadatos

CIL

CIL

Metadatos

Módulo Principal

EnsambladoMódulo 2 Módulo 3


ManifiestosManifiestosInteroperabilidad

• Todo ensamblado contiene un manifiesto(manifest): metadatos que describen el ensamblado y sus módulos. Consta de:� Dependencias con otros ensamblados (.assembly

extern)� Identificación de ensamblado (nombre)� Versión� Valor hash (CRC)� Clave pública (opcional)� Módulo principal (.module)� Módulos secundarios (.module extern)� Archivos adicionales (.file)� Información adicional de compiladores y

herramientas

13


DemoDemoInteroperabilidad

• Mostrar los manifiestos de los dos ensamblados:� ILDASM holacs.exe� ILDASM holavb.dll

• Crear un único ensamblado (único manifiesto) con todos los módulos de la aplicación:� VBC /target:module /out:holavb.dll holavb.vb� CSC /target:module /out:holacs.dll holacs.cs� AL holacs.dll,holavb.dll /target:exe /out:ens.exe

/main:HolaCS.Main� ILDASM ens.exe


Liberación AutomáticaLiberación AutomáticaGestión de Memoria

• En el desarrollo de aplicaciones de servidor la gestión automática de memoria es una tarea crítica:� Ejecución continua durante largos periodos� Múltiples clientes en aplicaciones multihilo� Utilización de protocolos stateless (HTTP)

• Una de las tareas del CLR es gestionar automáticamente la liberación automática de memoria: recolección de basura (Garbage Collection)

14


Infierno de las Infierno de las DLLsDLLsVersiones de Componentes

• Las aplicaciones se construyen mediante la utilización de componentes

• El mantenimiento de aplicaciones requiere el mantenimiento de los componentesempleados

• Los componentes sufren modificaciones y sus nuevas versiones reemplazan las antiguas

• La compatibilidad hacia atrás no se consigue en multitud de ocasiones:� Aplicaciones funcionaban correctamente, al instalar

nuevas aplicaciones, dejan de funcionar

• Este problema se conoce como “Infierno de las DLLs” (DLL Hell)


EnsambladosEnsambladosVersiones de Componentes

• La sobrescritura de DLLs y su registro en el Registry es eliminada en .net

• El concepto a utilizar es el de ensamblado:� Podrán coexistir diversas versiones del mismo

ensamblado en un mismo equipo� Los ensamblados no necesitarán entradas en el

Registry

• Existen dos tipos de ensamblados:� Privados a una aplicación (ej. ens.exe): Uso

exclusivo de una aplicación –basta con ubicarlo en su directorio

� Compartidos por aplicaciones: Se utiliza cuando se desea el componente sea accesible para cualquier aplicación

15


Ensamblados CompartidosEnsamblados CompartidosVersiones de Componentes

• Un ensamblado compartido se ubica en el GAC(Global Assembly Cache)\\winnt\assembly\ (Windows 2000)\\windows\assembly\ (Windows XP)

• Éste puede verse con el Assembly Cache Viewer que es una extensión del explorador de archivos

• No utiliza el Registry ni el Active Directory• Para manipular el GAC, tenemos la utilidad

GACUTIL del .net framework


Nombre SeguroNombre SeguroVersiones de Componentes

• Un nombre nombre seguro o compartido (strong name) consta de:1. Nombre (identificador)2. Clave pública del fabricante3. Versión

• Con 1 y 2, evitamos la colisión de nombres• Con 1, 2 y 3, evitamos la colisión de versiones• Los componentes se deben firmar desde el

VS.NET o con SN.exe del SDK

16


Llamadas al SistemaLlamadas al SistemaOrganización de Funciones

• La plataforma .net ofrece el acceso a sus librerías dentro del concepto de organización jerárquica “espacio de nombres” (namespace)

• La funcionalidad del sistema se ofrece por medio del espacio de nombres System

• El conjunto de funcionalidades se denomina librería de clases base (BCL, Base Class Library)System

System.Data System.Xml

System.Web

Globalization

Diagnostics

Configuration

Collections

Resources

Reflection

Net

IO

Threading

Text

ServiceProcess

Security

Design

ADO

SQLTypes

SQL

XPath

XSLT

RuntimeInteropServices

Remoting

Serialization

Serialization

Configuration SessionState

Caching Security

ServicesDescription

Discovery

Protocols

UIHtmlControls

WebControls

System.Drawing

Imaging

Drawing2DTextPrinting

System.WinFormsDesign ComponentModel


Interoperabilidad con COMInteroperabilidad con COMLegacy Code

• Existen múltiples aplicaciones desarrolladas para las antiguas plataformas Win32. La compatibilidad hacia atrás con este tipo de aplicaciones (lecacy code) es esencial para .net

• El CLR es capaz de interactuar con COM en dos sentidos para:� Acceder desde nuevas aplicaciones .net a módulos

o aplicaciones COM, sin necesidad de rescribir éstas

� Actualizar aplicaciones antiguas con nuevos módulos desarrollados en .net: acceso desde COM a .net

17


Acceso a COMAcceso a COMLegacy Code

• Un cliente .net tiene acceso a COM mediante RCW Runtime Callable Wrapper

• La utilidad TLBIMP del SDK permite crear el RCW a partir de un componente COM

• Importando el espacio de nombres, podemos crear objetos mediante new (CoCreateInstance)

• En el paso de mensajes se efectúa el marshalingde parámetros de .net a COM

• El decremento de la referencia a este objeto es gestionada por el recolector de basura

Cliente.net RCW

Componente COM


DemoDemoLegacy Code

• Desde VS.NET, “Project | Add Reference” se crea un espacio de nombres envoltorio que traduce su acceso al propio del componente COM

• Añadir una referencia Automation al WordWord.Application ap=new Word.ApplicationClass();

18


Acceso desde COMAcceso desde COMLegacy Code

• .net Framework permite que un cliente COM pueda acceder a objetos .net

• CCW, COM Callable Wrapper ofrece dicha funcionalidad:� El componente ha de estar firmado� El componente ha de estar en el GAC� La clase .net que sea accesible desde COM, debe

ofrecer un constructor sin parámetros� Es necesario incluir una entrada en el Registry,

mediante RegAsm.exe del SDK� Se crean los interfaces IUnknown e IDispatch

más los interfaces de las clases públicas

Clase.net

CCW ClienteCOM

IUnknown

IDispatch

MiInterface

MiInterface


Carencias de SeguridadCarencias de SeguridadSeguridad

• La mayoría de sistemas de seguridad se basan en listas de control de acceso (ACL)

• Este sistema de acceso es correcto para aplicaciones de escritorio, pero ¿qué sucede con la distribución de aplicaciones por medio de redes (Internet)?

• Authenticode es realmente un sistema de responsabilidad, no de seguridad: identifica quien produjo el daño, pero no lo evita

• Lo que se desea es limitar las operaciones que puedan realizar los distintos fragmentos de código en función del nivel de confianza (trustmanagement) que tengan

19


Acceso a RecursosAcceso a RecursosSeguridad

• El administrador otorga los niveles de confianza a los distintos ensamblados del sistema\\WINDOWS\Microsoft.NET\Framework\[version]\CONFIG\security.config

• El CLR ejecuta el código de las aplicaciones limitando el acceso a los recursos en base a su configuración

• Se puede dar un nivel de confianza (IPermission) a ensamblados agrupados por distintos criterios (PermissionSet)� Procedencia: Internet, LocalIntranet, Execution (Desktop)...

� Fabricante: ECMA, Microsoft, My_Computer_Zone, All_Code...

• Se trata pues de un sistema de privilegio de acceso a recursos por código, no usuario


DocumentaciónDocumentación

• S. Lidin. “Inside Microsoft .net IL Assembler” Microsoft Press, 2002

• J. Gough “Compiling for the .net Common Language Runtime” Bertrand Meyer Series Editor, 2002

• msdn.microsoft.com/net

� Download de .net Framework SDK� Documentación (Common Language Specification,

MS-IL Assembly Programmers Guide...)� Artículos de .net

• E. Meijer, J. Gough “Technical Overview of the Common Language Runtime” Microsoft.com, 2002

20

Universidad de Oviedo Departamento de Informática

Francisco Ortín SolerJunio, 2002

Microsoft .Microsoft .NetNetCLRCLR

((Common Language RuntimeCommon Language Runtime))

Microsoft .Net CLR Common Language Runtimedi002.edv.uniovi.es/~benja/cs/presentaciones/4-CLR.pdf · Introducción. 2 Francisco Ortín Soler Junio 2002.net Framework ... Máquina-P

Documents