.net - смарт - web3.js что это




Является ли.NET «всем COM под ним»? (5)

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

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

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

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

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

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

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

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

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

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

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

Juval Löwy: Конечно, все это COM под ним.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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


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








com