Hosting CLR rispetto a ClrCreateManagedInstance: quali sono i vantaggi?

Question

Ho implementato con successo l'interoperabilità tra l'applicazione Win32 e gestito la DLL .Net come descritto qui . Ma ho anche letto qui che è possibile ospitare il l'intero CLR all'interno del processo non gestito.

Quindi la mia domanda è: perché dovresti farlo? È un po 'più complesso del semplice utilizzo di un oggetto: quali vantaggi ottieni per questo prezzo di maggiore complessità?

Modifica: quello che ho capito da 2 prime risposte, è che hai la possibilità di personalizzare il CLR in base alle tue esigenze - il che significa che se stai scrivendo una semplice app aziendale, non avrai mai bisogno di ospitare. L'hosting è per cose pesanti come il browser o SQL Server.

Answer 1

L'hosting del CLR non è generalmente qualcosa che fai per interagire tra il codice gestito e Win32. ci sono generalmente 3 metodi di interoperabilità:

• Runtime Callable Wrapper (RCW): chiama un oggetto COM da .NET
• COM Callable Wrapper (CCW) - fa apparire un oggetto .NET come oggetto COM
• P / Invoke

Questi sono stati supportati dalla prima versione di .NET. Lo scopo principale dell'hosting del CLR è consentire di incorporare in profondità il codice .NET all'interno di un'applicazione non gestita. Ad esempio, esiste un modulo che può ospitare .NET in Apache su Win32 che consente di eseguire pagine aspx.

Allo stesso modo, SQL Server voleva un modo per le persone di scrivere procedure e funzioni memorizzate estese con codice gestito. In passato è possibile scriverli in C / C ++, ma se hanno ospitato il CLR potrebbero effettivamente consentire alle persone di scriverli con C #. Il lavoro per portare il CLR in uno stato in cui poteva essere incorporato in modo sicuro ha davvero spinto fuori le tempistiche, e così sono nate cose come il controllo sulla memoria e la sicurezza. SQL Server ha alcuni seri requisiti di stabilità e non puoi avere .NET a dondolare la barca.

L'API di hosting è cambiata significativamente da .NET 1.xa 2.x ma è stata più stabile da quando il CLR 2.0 è passato a .NET 3.0, 3.5 ecc.

Answer 2

Microsoft SQL Server lo utilizza ampiamente per sostituire sicurezza, caricamento degli assembly, gestione della memoria, gestione dei thread e quant'altro. Un buon libro su questo argomento è "Personalizzare il Common Language Runtime di Microsoft .NET Framework".

Answer 3

Potresti avere un'applicazione legacy e vuoi consentire a terze parti di utilizzare le strutture di .net dall'interno della tua applicazione, ma in particolare in modo controllato come da dove vengono caricati gli assiemi. Qui è un esempio.