Alojar CLR en lugar de usar ClrCreateManagedInstance, ¿cuáles son los beneficios?

Question

He implementado con éxito la interoperabilidad entre la aplicación Win32 y administré .NET dll como se describe aquí . Pero también leí aquí que es posible alojar el CLR completo dentro del proceso no administrado.

Entonces mi pregunta es: ¿por qué harías eso? Es algo más complejo que solo usar un objeto: ¿qué beneficios obtiene por este precio de mayor complejidad?

Editar: lo que entendí a partir de las 2 primeras respuestas, es que tienes la posibilidad de personalizar el CLR para tus necesidades, lo que significa que si estás escribiendo una aplicación empresarial simple, nunca tendrás que alojar. El hospedaje es para cosas pesadas en el sistema, como el navegador o el servidor SQL.

Answer 1

Hospedar el CLR generalmente no es algo que se hace para interoperar entre el código administrado y Win32. generalmente hay 3 métodos de interoperabilidad:

• Runtime Callable Wrapper (RCW): llama a un objeto COM desde .NET
• COM Callable Wrapper (CCW): hacer que un objeto .NET aparezca como un objeto COM
• P / Invocar

Estos han sido compatibles desde la primera versión de .NET. El objetivo principal de hospedar el CLR es permitirle incrustar profundamente el código .NET dentro de una aplicación no administrada. Por ejemplo, hay un módulo que puede alojar .NET en Apache en Win32 permitiendo ejecutar páginas .aspx.

De manera similar, SQL Server quería que las personas escribieran procedimientos y funciones almacenados extendidos con código administrado. En el pasado, se podían escribir en C / C ++, pero si albergaban el CLR, en realidad podían permitir que las personas las escribieran con C #. El trabajo para poner el CLR en un estado en el que se podría incrustar de forma segura realmente se eliminó de las líneas de tiempo, y así nacieron cosas como el control sobre la memoria y la seguridad. SQL Server tiene algunos requisitos serios de estabilidad y no puede tener .NET balanceando el barco.

La API de alojamiento cambió significativamente de .NET 1.x a 2.x pero ha sido más estable desde que el CLR 2.0 ha vivido a través de .NET 3.0, 3.5 etc.

Answer 2

Microsoft SQL Server lo usa extensivamente para reemplazar la seguridad, la carga de ensamblajes, la administración de memoria, la administración de subprocesos y lo que no. Un buen libro sobre este tema es " Personalización del Common Language Runtime de Microsoft .NET Framework " ;.

Answer 3

Es posible que tenga una aplicación heredada y desee permitir que terceros utilicen las instalaciones de .net desde su aplicación, pero particularmente de manera controlada como controlando desde donde se cargan los ensamblajes. Aquí es un ejemplo.