One of the things that came out of my conversations with clients last night was an interest in hosting .Net Core from native code. Of course we already host the CLR and provide an easy way to write servers that do the heavy lifting in native code and call out to managed code for the business logic. We have several clients using this to host managed “plugins” inside a native host and it works very well.
Last time I explained how the managed side of my flexible hosting server architecture was structured. I dealt with the IDL required to generate the COM interfaces which were used to communicate between unmanaged code and managed code and detailed how the custom AppDomainManager object allowed me to load and execute managed code in such a way that it was easy to update the managed applications whilst the server was running.
Whilst looking through the latest documentation for the AppDomainSetup class I see that you can now specify a new AppDomainManager object for each application domain that you create. This removes the duality of the pre 4.0 AppDomainManager as the manager that you specify when you start the CLR can now deal solely with the requirements of the default application domain and it can set a new AppDomainManager object for each application domain that it creates.
I’m working on some prototype code right now to improve the “deployment characteristics” of a socket server that I wrote for a client which uses CLR hosting to provide multiple managed applications within a single unmanaged host. The client wants to be able to start, stop and restart individual managed applications within the server so that during development or when a managed application is updated they don’t need to restart the whole unmanaged server process to use a new version of a managed application.
I’ve been playing with Visual Studio 2010 Beta 2 and .Net 4.0, building code, running tests, playing with the IDE, etc. The first issue that I’ve come across with my existing codebase is that the .Net 2.0 hosting APIs (such as CorBindToRuntimeEx)are now deprecated and there’s a whole new way of hosting the CLR. We’ve been quite successful in hosting the CLR from within our C++ servers, either to provide servers that support a mix of managed/unmanaged plugins as a pluggable high performance windows application server or to provide network protocol support in C++ (such as ENet) with ‘business logic’ being written in managed code.
I’m looking into adding CLR deadlock detection into the CLR hosting code that’s used inside The Server Framework and, once again, the fact that you can’t cleanly shutdown the CLR host is causing me problems… Since the CLR can’t be stopped by a host without terminating the host process (and that’s by design…) you need to be aware that any of the code that you have plugged into the CLR by way of the hosting interfaces can be called into during process shutdown.
It’s interesting, no, really, how the more things change the more they stay the same… I’ve been doing COM for a long time. I first discovered COM back at Interlink when I was writing a windows version of a product call CardMaster which did credit card production. The system supported lots of different machines and each of these machines needed different drivers, the drivers were written in C and usually spoke to the machine via a serial port.
I’ve spent some time over the last few days playing around with my CLR hosting socket server example. I had stalled on a piece of client work, I’ve got a bit of a head cold at the moment and my brain just wasn’t in the right place for what I was supposed to be doing so I picked up one of more interesting the items on my todo list and took a look at that instead… The bulk of the work flowed nicely but then, just at the end things stopped working for no apparent reason… I’d done what was suggested in the book, the code compiled, the CLR called into my host in the right way and then I got a security policy exception… Hmmm.
The work on the CLR hosting socket server example is going pretty well. I now have a server that can pass server notifications to managed code that either runs in an AppDomain per connection or within a single AppDomain (depending on how isolated you want the user code to be). I think I’m pretty much there as far as what I want to demonstrate is concerned; it works and the line between managed and unmanaged code is likely to vary depending on a client’s particular requirements so there’s little point in extending the example code any further.
My investigations into CLR hosting are going well and today I built an echo sever based on The Server Framework and my CLR Hosting helper library. The idea is that the server can deal with the network IO and then hand off the ‘real work’ to some .Net code. So far the integration is going pretty smoothly….