Est-ce que .NET est "tout COM en dessous"?

Question

J'ai été un admirateur de Juval Lowy de l'enseignement et de l'orientation dans les .NET développement pour un certain nombre d'années. Il a également écrit un de mes livres préférés: la Programmation .NET des Composants.

Cependant, lors d'une récente DotNet Roches podcast (Jan 2010) dans la discussion de la WCF/COM et .NET, il a fait quelques commentaires qui a grandement surpris moi:

Juval Löwy: ..... dans .NET, lo et voici, tous les cours ici, c'est un COM objet. Nous le savons. En fait, bien plus que de la COM, parce que nous avons eu le git de la compilation, nous avons de collecte des ordures, nous avons la Sécurité de la Pile....

Carl Franklin: eh Bien, vous devriez préciser que cependant. Je veux dire, tous les l'objet n'est pas un objet COM. Chaque objet possède les capacités d'un COM l'objet n', mais le .NET Framework n'est pas une bibliothèque COM.

Juval Löwy: non, Non. Tout d'abord .NET est en fait construit sur top de COM. C'est tout COM-dessous.

Puis, après Carl Franklin demande des éclaircissements sur ce commentaire:

Carl Franklin: Ouais, je le conçois. Mon la question était est .NET construit sur la COM?

Juval Löwy: bien sûr, tout COM en-dessous.

Carl Franklin: Aucun. Je sais que c'est étroitement liés et il est nécessaire, mais lorsque vous nouveaux un .NET de l'objet que vous êtes ne pas créer un objet COM.

Juval Löwy: Vous êtes à la création d'un .NET de l'objet, mais tous les Je suis en train de dire que .NET est construit en-dessous. C'est tout le C++, et COM.

Carl Franklin: C'est le C++, mais vous n'êtes pas l'enregistrement d'un objet COM à travers le L'interface COM. Ce n'est pas ce genre de trucs sauf si vous faites cela.

Juval Löwy: Mais c'est quelque chose de l'aide COM en dessous, mais c'est à côté de la point. Oublier comment il est fait.

Comment avez-vous lu ces commentaires?

Même si je comprends (et l'ont confirmé) que certains ensembles sont écrits en C++, est-il également valable pour dire qu'ils sont "tous COM en dessous"?

J'étais sous l'hypothèse qu'il est parfaitement possible d'écrire .NET compatible CLI C++ assemblées qui n'ont absolument rien à voir avec COM / ATL / ActiveX?

Voici le PDF de la transcription pour le podcast en question. Voir Page 7.

Answer 1

Je crois qu'il parle de l'implémentation sous-jacente de la CLR. De ma compréhension, il ne parle pas de l'interaction de la COM et .NET mondes. Il s'agit simplement de nous dire qu'ils ont utilisé le C++ et COM dans la mise en œuvre de l'exécution.

J'étais sous l'hypothèse qu'il est parfaitement possible d'écrire .NET compatible CLI C++ assemblées qui n'ont absolument rien à voir avec COM / ATL / ActiveX?

Oui, vous pouvez utiliser le C++/CLI pour créer purement MSIL assemblées qui n'ont rien à voir avec COM.

Answer 2

Dave Markle réponse m'a rappelé quelque chose Jeff de Richter dans CLR Via C#.

(Chapitre 21, CLR Hébergement et de domaines d'application)

L' .NET Framework s'exécute au-dessus de Microsoft Windows. Cela signifie que l' .NET Framework doit être construit à l'aide de les technologies que Windows peut interface avec. Pour commencer, tous les géré module et les fichiers d'assemblage doit utiliser le Windows fichier exécutable portable (PE) format de fichier et être, soit une EXE de Windows ou d'un fichier de liens dynamiques bibliothèque (DLL).

Lors de l'élaboration de la CLR, Microsoft mis en œuvre en tant que serveur COM contenue dans une DLL; c'est, Microsoft a défini un standard COM l'interface pour le CLR et affecté Guid de cette interface et de la COM serveur. Lorsque vous installez le .NET Cadre, le serveur COM représentant le CLR est enregistré dans Windows registre comme n'importe quel autre serveur COM. Si vous souhaitez plus d'informations sur à ce sujet, reportez-vous à la MSCorEE.h C++ fichier d'en-tête qui est livré avec .NET Framework SDK. Ce fichier d'en-tête définit le Guid et le non géré ICLRRuntimeHost définition de l'interface.

Je suppose que c'est à peu près à l'explication de Juval commentaires.

Alex DeLarge fait également un bon point dans une autre réponse que il y a une différence entre la mise en œuvre de la CLR lui-même et de la Bibliothèque de classes de Base des assemblages.

J'étais certainement en se concentrant sur la BCL assemblées (Juval: "chaque satc ici est un objet COM") et l'application des assemblées et c'est peut-être la cause de la confusion.

Answer 3

Je pense que Löwy parle spécifiquement de l'implémentation Windows de .NET. Comme COM est une énorme partie de l'infrastructure de Windows, il n'est pas étrange que .NET l'utilise. Cependant, .NET est également disponible sur des plateformes autres que Windows, donc je ne vois pas comment COM est à la base de .NET.

Answer 4

C'est presque comme si Löwy est volontairement tenter d'être claire dans ce qu'il dit. Je n'ai pas écouté le podcast, mais à en juger par les accents, je pense que l'anglais n'est pas sa première langue.

Certains objets que vous utilisez dans .NET sont vraiment des wrappers pour des objets COM. Et un .NET les objets que vous créez fait beaucoup de ce COM est censé faire, et de plus, sans COM méchant désagréments. Je ne pense pas que l'énoncé "c'est tout COM-dessous" est exacte ou claire.

Je souhaite que l'entrevue avait été avec Jeff Richter. ;-)

Answer 5

.NET/CLR a commencé sa vie à être une meilleure COM (Chapitre 1 de ce livre)

Mais il est n'est pas basé sur la COM comme il l'a enlevé beaucoup de zones à problèmes de de COM. (Comptage de référence en fonction de la mémoire de la gestion, de l'insécurité des pointeurs, des dépendances du registre..)

Mais il peut utiliser les objets COM et il peut envelopper .NET les objets dans la COM-emballage. Mais un .NET de l'objet n'est pas un objet COM.

L'accueil de l'interface pour le .NET mise en œuvre sur Windows est basé sur quelques interfaces COM.