Хостинг CLR по сравнению с использованием ClrCreateManagedInstance - каковы преимущества?

Question

Я успешно реализовал взаимодействие между Win32-приложением и управлял .Net dll, как описано здесь . Но я также прочитал здесь , что можно разместить весь CLR внутри неуправляемого процесса.

Итак, мой вопрос: зачем ты это делаешь? Это несколько сложнее, чем просто использовать объект - какие преимущества вы получаете за эту цену повышенной сложности?

Редактировать: я понял из двух первых ответов, что у вас есть возможность настроить CLR для ваших нужд - это означает, что если вы пишете простое бизнес-приложение, вам никогда не потребуется хостинг. Хостинг предназначен для таких системных задач, как браузер или SQL Server.

Answer 1

Размещение CLR, как правило, не то, что вы делаете для взаимодействия между управляемым кодом и Win32. обычно существует 3 метода взаимодействия:

• Runtime Callable Wrapper (RCW) - вызов COM-объекта из .NET
• COM Callable Wrapper (CCW) - сделать объект .NET видимым как COM-объект
• P / Invoke

Они поддерживаются с первой версии .NET. Весь смысл размещения CLR заключается в том, чтобы позволить вам глубоко внедрить код .NET в неуправляемое приложение. Например, есть модуль, который может размещать .NET в Apache на Win32, позволяя ему запускать страницы .aspx.

Аналогично, SQL Server хотел, чтобы люди могли писать расширенные хранимые процедуры и функции с помощью управляемого кода. В прошлом вы могли писать их на C / C ++, но если бы они размещали CLR, они могли бы действительно позволить людям писать это с C #. Работа по приведению CLR в состояние, в котором он мог бы быть безопасно встроен, действительно вытеснила временные рамки, и таким образом появились такие вещи, как контроль над памятью и безопасность. SQL Server предъявляет некоторые серьезные требования к стабильности, и у вас не может быть .NET покачивая лодку.

API хостинга значительно изменился с .NET 1.x на 2.x, но стал более стабильным, так как 2.0 CLR прошел через .NET 3.0, 3.5 и т. Д.

Answer 2

Microsoft SQL Server использует его экстенсивно, чтобы заменить безопасность, загрузку сборок, управление памятью, управление потоками и что нет. Хорошая книга на эту тему - «Настройка общеязыковой среды выполнения Microsoft .NET Framework».

Answer 3

У вас может быть унаследованное приложение, и вы хотите разрешить третьим сторонам использовать средства .net из вашего приложения, но особенно контролируемым образом , например, , контролируя, где сборки загружаются из. Здесь является примером.