visual cli .net c++ com

cli - ¿Es.NET "todo COM debajo"?



c++/cli (7)

He sido un admirador de la enseñanza y orientación de Juval Lowy en el desarrollo de .NET durante varios años. También escribió uno de mis libros favoritos: Programming .NET Components.

Sin embargo, en un reciente podcast de DotNet Rocks (enero de 2010) al analizar WCF / COM y .NET, hizo algunos comentarios que me sorprendieron enormemente:

Juval Löwy: ..... en .NET, y he aquí, cada clase aquí es un objeto COM. Lo sabemos. De hecho, es mucho más que COM porque tenemos la compilación de git, tenemos recolección de basura, tenemos la Pila de seguridad ...

Carl Franklin: Bueno, deberías aclarar eso sin embargo. Quiero decir, cada objeto no es un objeto COM. Cada objeto tiene las capacidades que tiene un objeto COM, pero .NET Framework no es una biblioteca COM.

Juval Löwy: No, no. En primer lugar, .NET está construido sobre COM. Todo es COM debajo.

Luego, después de que Carl Franklin solicita una aclaración sobre este comentario:

Carl Franklin: Sí, entiendo eso. Mi pregunta fue: .NET está basado en COM?

Juval Löwy: Por supuesto, todo COM por debajo.

Carl Franklin: No. Sé que está entrelazado y es necesario, pero cuando se crea un objeto .NET no se crea un objeto COM.

Juval Löwy: Estás creando un objeto .NET, pero todo lo que digo es que .NET se construye debajo. Es todo C ++ y COM.

Carl Franklin: Es C ++ pero no está registrando un objeto COM a través de la interfaz COM. No es todo eso a menos que específicamente lo hagas.

Juval Löwy: Pero algunas cosas están usando COM debajo, pero eso no viene al caso. Olvídate de cómo está hecho.

¿Cómo lees estos comentarios?

Si bien entiendo (y he confirmado) que algunos de los ensamblados del sistema están escritos en C ++ no administrado, ¿también es válido decir que son "todos COM debajo"?

Estaba bajo la suposición de que es perfectamente posible escribir ensamblajes C ++ .NET CLI que no tienen absolutamente nada que ver con COM / ATL / ActiveX.

Aquí está la transcripción en PDF para el podcast en cuestión. Ver página 7.

.NET / CLR comenzó su vida para ser un mejor COM (Capítulo 1 en este libro )

Pero no se basa en COM ya que eliminó muchas de las áreas problemáticas de COM. (Recuento de referencias basado en gestión de memoria, punteros inseguros, dependencias de registro ...)

Pero puede usar objetos COM y puede envolver objetos .NET en COM-wrapping. Pero un objeto .NET no es un objeto COM.

La interfaz de alojamiento para la implementación .NET en Windows se basa en unas pocas interfaces COM.

Creo que Löwy está hablando específicamente sobre la implementación de Windows de .NET. Como COM es una gran parte de la infraestructura de Windows, no es extraño que .NET lo use. Sin embargo, .NET también está disponible en plataformas que no son de Windows, así que no veo cómo COM es la base para .NET.

Creo que está hablando de la implementación subyacente del CLR. Desde mi entendimiento, él no está hablando de la interacción de los mundos COM y .NET. Simplemente nos dice que han utilizado C ++ y COM en la implementación del tiempo de ejecución.

Estaba bajo la suposición de que es perfectamente posible escribir ensamblajes C ++ .NET CLI que no tienen absolutamente nada que ver con COM / ATL / ActiveX.

Sí, puede usar C ++ / CLI para crear ensamblajes puramente MSIL que no tienen nada que ver con COM.

Es casi como si Löwy intencionadamente no fuera claro en lo que dice. No he escuchado el podcast, pero a juzgar por las diéresis, creo que el inglés no es su primer idioma.

Algunos objetos que usa en .NET realmente son envoltorios para objetos COM. Y un objeto .NET que cree hace mucho de lo que COM debe hacer y más, sin las desagradables molestias de COM. No creo que la declaración "todo es COM debajo" sea precisa o clara.

Ojalá la entrevista hubiera sido con Jeff Richter. ;-)

La respuesta de Dave Markle me recordó algo que Jeff Richter dijo en CLR Via C # .

(Capítulo 21, CLR Hosting y AppDomains)

.NET Framework se ejecuta sobre Microsoft Windows. Esto significa que .NET Framework debe construirse utilizando tecnologías con las que Windows pueda interactuar. Para empezar, todos los archivos de módulos y ensamblados administrados deben usar el formato de archivo ejecutable portátil (PE) de Windows y ser un archivo EXE de Windows o una biblioteca de vínculos dinámicos (DLL).

Al desarrollar CLR, Microsoft lo implementó como un servidor COM contenido dentro de una DLL; es decir, Microsoft definió una interfaz COM estándar para el CLR y los GUID asignados a esta interfaz y al servidor COM. Cuando instala .NET Framework, el servidor COM que representa el CLR se registra en el registro de Windows como cualquier otro servidor COM. Si desea obtener más información sobre este tema, consulte el archivo de encabezado C ++ MSCorEE.h que se incluye con .NET Framework SDK. Este archivo de encabezado define los GUID y la definición de la interfaz ICLRRuntimeHost no administrada.

Supongo que esto está muy cerca de explicar los comentarios de Juval.

Alex DeLarge también resalta en otra respuesta que existe una diferencia entre la implementación del CLR mismo y los ensamblajes de la Biblioteca de clases base.

Definitivamente me estaba enfocando en los ensamblajes BCL (Juval: "cada clss aquí es un objeto COM") y los ensamblajes de aplicaciones, por lo que esta puede ser la causa de la confusión.

Lo escuché y mi impresión fue que, aunque no estaba 100% claro, hablaba más sobre el tiempo de ejecución de .NET que el BCL.