Here’s a useful matrix which shows when each version of Visual Studio will become unsupported by Microsoft. I’m posting the link here as I’m sure I’ll not be able to find it the next time I need it…

Previously on “Practical Testing”… I’m writing a timer wheel which matches the interface used by my timer queue. This new implementation is designed for a particular usage scenario with the intention of trading space for speed and improving performance of some reliable UDP code. Over the last four entries I’ve implemented various parts of the timer wheel and adjusted the test code so that I could reuse the tests that I already had for the other implementations with my timer wheel.

Rather than immediately dive into the fun of writing my own invasive alternative for std::map I decided to take a look at what has been done before, as expected boost contains something that might work in the shape of the “intrusive containers library”. Of course, being part of boost I first have to work out exactly how much more of boost it will require me to depend on and then I have to work out how I can use it to replace my current std::map usage.

As I mentioned a while ago, I have some code which needs to perform better than it currently does and one of the areas that could be improved upon is the amount of contention for the heap that’s occurring. The fact that I’m using an STL map for my collection means that the class has a ‘big C’ contention value of C(n threads using the heap) rather than C(n threads using the object).

Previously on “Practical Testing”… To deal with some specific usage scenarios of a piece of general purpose code I’m in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in this series of articles. Last time I left myself with a failing test. The problem is that setting a new timer on the timer wheel sets a timer that’s relative to the time that timer wheel thinks is ’now’ and the timer wheel’s view of the current time could be slightly behind reality; see the previous entry for a diagram that explains the problem.

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 recently been adjusting my CLR hosting code as a client wanted to be able to host the .Net 4.0 runtime. Previously they were hosting the 2.0 runtime and, as I mentioned a while back, the hosting API has changed with 4.0. Switching to hosting 4.0 was easy enough but being able to fall back to hosting 2.0 on a machine where 4.0 wasn’t installed is slightly more complex. It’s reasonably obvious (you need to make sure that you call GetProcAddress() to bind to CLRCreateInstance() rather than linking to it at build time), but Brad Wilson has a nice list of steps to show how it’s done here on his blog.

One of the problems of having a collection of tools that interoperate is that there’s often a lag between when a tool will interoperate with the latest version of another tool. I’m hardly a bleeding-edge tool junky, I wait until RTM before I start using the latest Visual Studio on a daily basis, and in the case of VC 6 I stuck with it (as did most of my clients) until VS2005 came out and actually improved life for unmanaged C++ development… However, it seems that some tools take a long long time to catch up with Visual Studio.

Previously on “Practical Testing”… To deal with some specific usage scenarios of a piece of general purpose code I’m in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in this series of articles. The timer wheel trades space for speed and so far the development has gone well as I’ve been able to use the tests that I had already developed for the previous implementations to guide the new development.