Является ли .NET "всем COM под ним"?

Я был поклонником обучения и руководства Juval Lowy в области разработки .NET на протяжении ряда лет. Он также написал одну из моих любимых книг: "Программирование компонентов .NET".

Однако в недавнем подкасте DotNet Rocks (январь 2010 года) в обсуждении WCF/COM и .NET он сделал несколько замечаний, которые меня очень удивили:

Juval Löwy:..... в .NET, lo и вот, каждый класс здесь COM объект. Мы это знаем. На самом деле это намного больше, чем COM, потому что мы получил компиляцию git, у нас есть сбор мусора, у нас есть стек безопасности...

Карл Франклин: Ну, вы должны уточнить, что хоть. Я имею в виду, каждый объект не является COM-объектом. каждый объект имеет возможности, которые COM объект, но .NET Framework не является библиотекой COM.

Ювал Лёви: Нет, нет. В первую очередь .NET на самом деле построен на сверху COM. Это все COM внизу.

Затем, после того, как Карл Франклин попросит разъяснения по этому комментарию:

Карл Франклин: Да, я понял. мой вопрос был .NET построен на COM?

Juval Löwy: Конечно, все COM внизу.

Карл Франклин: Нет. Я знаю, что это переплетены и необходимы, но когда вы новичок в объекте .NET, вы не создавая COM-объект.

Juval Löwy: Вы создаете объект .NET, но все Я говорю, что .NET построен под. Все это С++ и COM.

Карл Франклин: Это С++, но вы не регистрации объекта COM через COM-интерфейс. Это еще не все если вы специально этого не делаете.

Juval Löwy: Но некоторые вещи используются COM внизу, но что рядом с точка. Забудьте о том, как это сделано.

Как вы читаете эти комментарии?

Пока я понимаю (и подтвердил), что некоторые сборки системы написаны на неуправляемом С++, также справедливо ли утверждать, что они "все COM под ним"?

Я был в предположении, что вполне возможно написать .NET С++-сборки, совместимые с CLI, которые не имеют абсолютно никакого отношения к COM/ATL/ActiveX?

Вот PDF-расшифровка для рассматриваемого подкаста. См. Стр. 7.

Ответ 1

Это почти так, как если бы Лёво намеренно пытался не понимать, что он говорит. Я не слушал подкаст, но, судя по умлаутам, я считаю, что английский не является его первым языком.

Некоторые объекты, которые вы используете в .NET, действительно являются оболочками для COM-объектов. И объект .NET, который вы создаете, делает многое из того, что COM должен делать, и многое другое, без COM неприятных неприятностей. Я не думаю, что утверждение "все COM под ним" является точным или ясным.

Я хотел бы, чтобы интервью было с Джеффом Рихтером.; -)

Ответ 2

Я думаю, что он говорит о базовой реализации CLR. Насколько я понимаю, он не говорит о взаимодействии миров COM и .NET. Он просто говорит нам, что они использовали С++ и COM в реализации среды выполнения.

Я был в предположении, что вполне возможно написать .NET С++-сборки, совместимые с CLI, которые не имеют абсолютно никакого отношения к COM/ATL/ActiveX?

Да, вы можете использовать С++/CLI для создания чисто сборников MSIL, которые не имеют ничего общего с COM.

Ответ 3

Я считаю, что Lewwy конкретно говорит о реализации .NET в .NET. Поскольку COM - такая огромная часть инфраструктуры Windows, не странно, что .NET использует это. Тем не менее,.NET доступен на не-Windows-платформах, а также, поэтому я не вижу, как COM является основой для .NET.

Ответ 4

Ответ Дейва Маркла напомнил мне о чем-то, что Джефф Рихтер сказал в CLR Via С#.

(Глава 21, Хостинг CLR и AppDomains)

.NET Framework работает поверх Майкрософт Виндоус. Это означает, что .NET Framework должна быть построена с использованием технологий, которые Windows может интерфейс с. Во-первых, все управляемый модуль и файлы сборки должны использовать исполняемый файл Windows (PE) и быть либо Файл Windows EXE или динамическая ссылка библиотеки (DLL).

При разработке среды CLR Microsoft реализовал его как COM-сервер содержащихся внутри DLL,, то есть, Microsoft определила стандартный COM интерфейс для CLR и назначенный GUID для этого интерфейса и COM сервер. Когда вы устанавливаете .NET. Framework, COM-сервер, представляющий CLR зарегистрирована в Windows как и любой другой COM-сервер. Если вам нужна дополнительная информация о этот раздел, обратитесь к MSCorEE.h С++ файл заголовка, который поставляется с .NET. Рамочный SDK. Этот заголовочный файл определяет идентификаторы GUID и неуправляемые Определение интерфейса ICLRRuntimeHost.

Я предполагаю, что это довольно близко к объяснению комментариев Juval.

Alex DeLarge также дает хороший ответ в другом ответе, что существует разница между реализацией самой CLR и сборками библиотеки базового класса.

Я, конечно, сосредоточился на сборках BCL (Juval: "каждый clss здесь является COM-объектом" ) и сборками приложений, поэтому это может быть причиной путаницы.

Ответ 5

.NET/CLR начал жизнь как лучший COM (глава 1 в в этой книге)

Но он не основан на COM, поскольку он удалил много проблемных областей COM. (Управление учетными данными на основе подсчета ссылок, небезопасные указатели, зависимости реестра).

Но он может использовать COM-объекты, и он может переносить объекты .NET в COM-wrapping. Но объект .NET не является COM-объектом.

Интерфейс хостинга для реализации .NET в Windows основан на нескольких COM-интерфейсах.

Ответ 6

Я думаю из this и в присутствии ICLRRuntimeHost и различные другие неуправляемые интерфейсы к внутренним средам CLR, довольно очевидно, что .NET фактически построен поверх COM.

Ответ 7

Я слушал это, и я думал, что, хотя он не на 100% понятен, он больше рассказывал о времени выполнения .NET, чем BCL.