Hébergement de CLR ou utilisation de ClrCreateManagedInstance - quels sont les avantages?

Question

J'ai implémenté avec succès interop entre une application Win32 et une dll .Net gérée, comme décrit ici . Mais j’ai aussi lu ici qu’il est possible d’héberger le CLR entier à l'intérieur du processus non géré.

Donc ma question est: pourquoi voudriez-vous faire cela? C’est un peu plus complexe que de simplement utiliser un objet. Quels avantages en retirez-vous pour ce prix d’une complexité accrue?

Modifier: ce que j’ai compris des 2 premières réponses, c’est que vous avez la possibilité de personnaliser le CLR en fonction de vos besoins - ce qui signifie que si vous écrivez une simple application professionnelle, vous n’avez jamais besoin d’héberger. L'hébergement est destiné à des applications système, telles que le navigateur ou SQL Server.

Answer 1

L’hébergement du CLR n’est généralement pas une opération que vous faites pour interopérer entre le code managé et Win32. il y a généralement 3 méthodes d'interopérabilité:

• Runtime Callable Wrapper (RCW) - appelle un objet COM depuis .NET
• COME Callable Wrapper (CCW) - permet à un objet .NET d’apparaître en tant qu’objet COM
• P / Invoke

Ceux-ci sont pris en charge depuis la première version de .NET. L’intérêt d’héberger le CLR est de vous permettre d’intégrer profondément du code .NET dans une application non gérée. Par exemple, un module peut héberger .NET dans Apache sous Win32, lui permettant d'exécuter des pages .aspx.

De même, SQL Server cherchait un moyen d'écrire des procédures stockées étendues et des fonctions avec du code managé. Dans le passé, vous pouviez les écrire en C / C ++, mais s'ils hébergeaient le CLR, ils pouvaient en réalité permettre aux gens de les écrire en C #. Le travail nécessaire pour que le CLR se retrouve dans un état où il pourrait être intégré en toute sécurité a vraiment repoussé les délais, et ainsi sont nés des éléments tels que le contrôle de la mémoire et la sécurité. SQL Server a de sérieuses exigences en matière de stabilité et vous ne pouvez pas laisser .NET faire des vagues.

L’API d’hébergement a considérablement changé, passant de .NET 1.x à 2.x, mais est plus stable depuis que le CLR 2.0 a traversé .NET 3.0, 3.5, etc.

.

Answer 2

Microsoft SQL Server l’utilise fréquemment pour remplacer la sécurité, le chargement de l’assemblage, la gestion de la mémoire, la gestion des threads, etc. Un bon livre sur ce sujet est "Personnalisation de l'exécution de Microsoft .NET Framework Common Language Runtime".

Answer 3

Vous possédez peut-être une application héritée et souhaitez autoriser des tiers à utiliser les fonctionnalités de .net à partir de votre application, mais en particulier de manière contrôlée tel que où les assemblées sont chargées. Voici un exemple.