Hébergement CLR contre l'utilisation de ClrCreateManagedInstance - quels sont les avantages?

Question

J'ai implémenté avec succès l'application interop beftween Win32 et la DLL .Net gérée comme décrit here. Mais je lis aussi here qu'il est possible d'héberger tout le CLR à 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 vous en retirer pour ce prix de complexité accrue? Edit: ce que j'ai compris de 2 premières réponses, c'est que vous avez la possibilité de personnaliser le CLR pour vos besoins - ce qui signifie que si vous écrivez une application d'entreprise simple, vous n'aurez jamais besoin d'héberger. L'hébergement est pour les choses système-lourds, comme le navigateur ou SQL Server.

Answer 1

L'hébergement du CLR n'est généralement pas une opération que vous effectuez pour interopérer du code managé avec Win32. il y a généralement 3 méthodes de Interop:

• Runtime Callable Wrapper (RCW) - appeler un objet COM de .NET
• COM Callable Wrapper (CCW) - faire un objet .NET apparaît comme un objet COM
• P/Invoke

Celles-ci ont été prises en charge depuis la première version de .NET. Le but de l'hébergement du CLR est de vous permettre d'intégrer le code .NET dans une application non gérée. Par exemple, il existe un module qui peut héberger .NET dans Apache sur Win32 lui permettant d'exécuter des pages .aspx. De même, SQL Server voulait que les personnes puissent é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 fait permettre aux gens d'écrire ceux-ci avec C#. Le travail pour mettre le CLR dans un état où il pourrait être intégré en toute sécurité a vraiment poussé les délais, et ainsi des choses comme le contrôle de la mémoire et la sécurité sont nés. SQL Server a des exigences de stabilité sérieuses et vous ne pouvez pas avoir .NET bascule le bateau.

L'API d'hébergement a changé de manière significative de .NET 1.x à 2.x, mais a été plus stable depuis le 2.0 CLR a vécu dans .NET 3.0, 3.5 etc.

Answer 2

Vous pouvez avoir une application héritée et que vous souhaitez permettre à 3e parties à l'utilisation des installations de .net à partir de votre application, mais surtout d'une manière tels que contrôlé contrôle où les ensembles sont chargés à partir. Here est un exemple.

Answer 3

Microsoft SQL Server l'utilise extensivly pour remplacer la sécurité, le chargement d'assembly, la gestion de la mémoire, la gestion des threads et quoi d'autre. Un bon livre sur ce sujet est "Personnalisation de Microsoft .NET Framework Common Language Runtime".