.Net

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.

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….

Nice to see that the new beta, sorry, CTP, of the next .Net Framework will increase the performance of .Net sockets by 70%! Way to go .Net dudes…. Interesting to see that it’s a joint effort between the System.Net people (who, I assume own the sockets code) and the CLR people (who own the platform)… I wonder what the CLR guys brought to the tuning table… It would be nice to know how the new (and existing) .

Back in July Joe Duffy wrote an interesting piece on the CLR thread pool. I commented on it then, here. He’s now written another piece about why they increased the maximum number of threads in “the thread pool” from 25/cpu to 250/cpu. Joe, I refer you to my previous comment… You’re solving the wrong problem!

This is mainly a reminder for me so that I can read this when I get back from Jackson Hole… Dino Viehland has written some interesting looking blog posts on how to implement the thread/task and syncrhonisation host managers for a hosted CLR. Note that this is all “Whidbey beta 1” stuff so, well, your milage may vary…

I’m still playing with hosting the CLR in C++ (using “Customizing the Microsoft.NET Framework Common Language Runtime” by Steven Pratschner as my guide)… It’s an interesting journey but, once again, I wonder who makes the important technical decisions at Microsoft and how they sleep at night ;) . I’m currently playing with the ICLRRuntimeHost interface. This lets you load the CLR into your unmanaged process and gives you a remarkable amount of control over how the CLR that you’re hosting operates.

I’m playing around with hosting the CLR in C++ at present and have come across a bit of crapness in the mscoree.h file… #if (_MSC_VER < 1300 || _WIN32_WINNT < 0x0500) typedef VOID ( __stdcall *WAITORTIMERCALLBACK )( PVOID __MIDL_0011, BOOL __MIDL_0012); #endif // (_MSC_VER < 1300 || _WIN32_WINNT < 0x0500) This effectively says, if you’re using VC6 or you’re compiling for less than v5 of Windows NT then you don’t have this typedef so here it is… Unfortunately, if you’re compiling with VC6 but you’re using the platform SDK then you already have that typedef in winbase.