.NET "все COM под"? - PullRequest
       20

.NET "все COM под"?

34 голосов
/ 17 февраля 2010

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

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

Ювал Леви: ..... в .NET, вот и вот, каждый класс здесь является COM объект. Мы знаем это. На самом деле, это намного больше, чем COM, потому что мы есть компиляция GIT, у нас есть сборка мусора, у нас есть стек безопасности ...

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

Ювал Леви: Нет, нет. Прежде всего .NET на самом деле построен на верхняя часть COM. Это все COM внизу.

Затем, после того, как Карл Франклин просит пояснить этот комментарий:

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

Ювал Леви: Конечно, все это COM внизу.

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

Ювал Леви: Вы создаете объект .NET, но все Я говорю, что .NET построен под. Это все C ++ и COM.

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

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

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

Хотя я понимаю (и подтвердил), что некоторые из системных сборок написаны на неуправляемом C ++, можно ли также сказать, что они «все под COM»?

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

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

Ответы [ 7 ]

20 голосов
/ 17 февраля 2010

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

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

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

16 голосов
/ 17 февраля 2010

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

15 голосов
/ 17 февраля 2010

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

(Глава 21, Хостинг CLR и домены приложений)

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

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

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

В другом ответе Алекса ДеЛарга также подчеркивается, что есть разница между реализацией самого CLR и сборок библиотеки базовых классов.

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

7 голосов
/ 17 февраля 2010

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

Некоторые объекты, которые вы используете в .NET, действительно являются обертками для объектов COM. И созданный вами объект .NET делает многое из того, что должен делать COM, и даже больше, без неприятных раздражений COM. Я не думаю, что утверждение «все это под СОМ» является точным или ясным.

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

6 голосов
/ 17 февраля 2010

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

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

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

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

3 голосов
/ 17 февраля 2010

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

2 голосов
/ 17 февраля 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...