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.
Hosting the CLR is generally not something you do to interop between managed code and Win32. there are generally 3 methods of interop:
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.