2011-07-07 18 views
24

He estado desarrollando aplicaciones usando .net por bastante tiempo. Pero, todavía no estoy seguro, ¿cómo sabe el CLR que una aplicación .net ha comenzado. ¿Hay como una instancia de CLR por aplicación? No creo que este sea el caso, ya que solo hay un GC que gestiona toda la memoria de todas las aplicaciones .net. ¿El tipo de CLR se ejecuta en segundo plano? Estoy bastante confundido.¿Qué sucede cuando se inicia una aplicación .net?

+0

¿Qué te hizo pensar: "solo hay un GC que gestiona toda la memoria para todas las aplicaciones .net"? –

+0

¿Qué te hace pensar que solo hay un GC para todas las aplicaciones? – blowdart

+2

También puede consultar [esto] (http://social.msdn.microsoft.com/Forums/en-US/clr/thread/238c5f43-1d12-4c80-a987-0b8fdfd6d7e4) – V4Vendetta

Respuesta

6

Los ejecutables de Windows son Portable Executables, un formato que proporciona a Windows la información que necesita para cargar y ejecutar el programa. Cuando Windows encuentra un programa .NET, carga una instancia del CLR y ejecuta el programa en la nueva instancia CLR. Cada programa .NET en ejecución se aloja dentro de su propia instancia del CLR.

El proceso CLR carga el programa IL y lo compila a código nativo (JIT) y luego ejecuta el código, teniendo en cuenta la administración de la memoria y la recolección de basura para ese programa.

+7

Esto hace que parezca que Windows sabe la aplicación es .NET y Windows deberían cargar el clr. Ese no es el caso. El exe básicamente contiene un bootstrapper nativo que carga el .NET clr y pone en marcha el proceso administrado. En lo que respecta a Windows, acaba de lanzar una aplicación nativa y esa aplicación cargó algunos dll. –

35

Hmm, déjame echar un vistazo a esto también.

  1. Alguien crea una aplicación .NET en C#, o .NET 'Intermediate Language' u otro lenguaje administrado.

  2. El compilador para ese idioma csc.exe (C#), o ilasm.exe (ensamblador de códigos de bytes), o lo que sea, produce un ejecutable de PE. El ejecutable PE tiene una estructura específica que el compilador o ensamblador rellena. Eso incluye:

    • un punto de entrada, y
    • una lista de librerías dinámicas que se utiliza (la tabla de importación). Una de esas bibliotecas es mscoree.dll
    • gran cantidad de metadatos, incluyendo la versión de tiempo de ejecución .NET dirigido
  3. Cuando se hace clic en el archivo ejecutable en, corrió desde la línea de comandos o ejecutar desde una API de Win32, el Windows loader implementation (en NTDLL.dll) toma el control

  4. El código del cargador es responsable de obtener el ejecutable en la memoria, cargar bibliotecas de enlaces dinámicos si es necesario, asignar bibliotecas vinculadas a un lugar donde el código ejecutable pueda alcanzarlas y actualizar la tabla de direcciones de importación con las direcciones reales de las bibliotecas mapeadas.

  5. Una vez que todo está listo, el cargador salta al punto de entrada (a través de lo que supongo son algunas travesuras que cambian del espacio del núcleo al espacio de usuario, o al modo protegido, ya que la aplicación corre en sus propios 32 o 64 bits protegidos espacio de memoria). El punto de entrada va a mscoree.dll, el motor de ejecución de objetos comunes de .NET, que acaba de asignarse a la memoria de procesos. He visto este archivo DLL denominado shim de arranque de .NET, y permite que las múltiples instalaciones de .NET existan en una máquina. Mscoree.dll es la biblioteca que usará si está integrando un lenguaje .NET en su propia aplicación habitual.

  6. Mscoree.dll observa los metadatos cargados desde el ejecutable PE, específicamente el encabezado CLR, y la versión de tiempo de ejecución .NET. De eso puede CorBindToRuntimeEx 2 a la versión CLR correcta.

  7. CorBindToRuntimeEx carga la implementación de tiempo de ejecución .NET correcta (y devuelve un puntero a una interfaz COM que le permite invocar ese tiempo de ejecución .NET Este código se carga desde las DLL en% WINDIR% \ Microsoft.NET \ Framework \ v #####.

  8. No estoy seguro de quién en este punto, pero probablemente el mscoree shim utiliza el puntero de interfaz .NET ICLRRuntimeHost para invocar métodos para inicializar las interfaces .NET runtime, garbage collector, IL intérprete, JIT e IHostControl (que permiten el intérprete de .NET para responder al proceso de alojamiento), y finalmente le dice al intérprete que empiece a ejecutar el código IL de su aplicación compilada.

(I aprendido mucho escribir este - hay un montón de información detrás de los enlaces, ciertamente no conseguir a través de toda ella)

http://msdn.microsoft.com/en-us/library/xh0859k0.aspx

http://my.safaribooksonline.com/book/programming/microsoft-dotnet/0735619883/a-tour-of-the-clr-hosting-api/ch02lev1sec3

http://msdn.microsoft.com/en-us/magazine/bb985994.aspx

+0

Respuesta muy bien escrita y detallada. Y, afaik, incluso es todo correcto también. :) –

+1

¿Por qué no se acepta esta respuesta? –

+1

¡Excelente respuesta! Esto debe ser aceptado! – Sam

Cuestiones relacionadas