Hosting CLR versus using ClrCreateManagedInstance - what are the benefits?

I have successfully implemented interop beftween Win32 application and managed .Net dll as described here. But I also read here that it is possible to host the entire CLR inside of the unmanaged process.

So my question is: why would you do that? It is somewhat more complex than just use an object - what benefits you gain for this price of increased complexity?

Edit: what I understood from 2 first answers, is that you get the possibility to customize the CLR for your needs - meaning if you're writing a simple business app, you'll never need to host. Hosting is for system-heavy stuff, like browser or SQL Server.

From stackoverflow

• You may have a legacy application and want to allow 3rd parties to the use the facilities of .net from within your application but particularly in a controlled manner such as controlling where assemblies are loaded from. Here is an example.

  Sergey Aldoukhov : Good link, thanks. Still, my question was more around of why you need more control.

• Microsoft SQL Server uses it extensivly to replace the security, assembly loading, memory management, thread management and what not. A good book about this subject is "Customizing the Microsoft .NET Framework Common Language Runtime".

• Hosting the CLR is generally not something you do to interop between managed code and Win32. there are generally 3 methods of interop:

  • Runtime Callable Wrapper (RCW) - call a COM object from .NET
  • COM Callable Wrapper (CCW) - make a .NET object appear as a COM object
  • P/Invoke

  These have been supported since the first version of .NET. The whole point of hosting the CLR is to allow you to deeply embed .NET code inside an unmanaged application. For example, there is a module that can host .NET in Apache on Win32 allowing it run .aspx pages.

  Similarly, the SQL Server wanted a way for people to write extended stored procedures and functions with managed code. In the past you could write these in C/C++, but if they hosted the CLR they could actually allow people to write these with C#. The work to get the CLR into a state were it could be safely embedded really pushed out the timelines, and so things like control over memory and security were born. SQL Server has some serious stability requirements and you can't have .NET rocking the boat.

  The hosting API changed significantly from .NET 1.x to 2.x but has been more stable since the 2.0 CLR has lived through .NET 3.0, 3.5 etc.