As I said a while ago, Visual Studio 2015 appears to have lots of pretty serious bugs. One that probably bites me more than many people is this Save As bug. If you have a project and you select a file in that project and do a “Save As” such that the target file is also in the project then the VS2015 IDE crashes. I tweeted about this a while back, and the Visual Studio Program Manager, Cathy Sullivan, wanted me to create a new project and see if the problem happened with it… Not quite sure why she couldn’t do this herself, but anyway, here’s a zip of a project created with VS2015 where there’s a file called SaveMeAsTargetver.

Version 6.6.3 of The Server Framework was released today. This release is mainly a bug fix release but it also adds support for Visual Studio 2015 and Windows 10 (though we don’t explicitly use any Windows 10 APIs). There are quite a lot of small changes due to us running Gimpel Lint over the code. Most of the changes will have fixed potential issues rather than issues that have actually been reported.

As usual I have used VMs to play with the CTP releases for the new version of Visual Studio and fixed up new warnings and build failures in my source so that I’m not too surprised when the RTM comes along. Unfortunately as soon as I put VS2015 RTM on my build server and started running it as part of my CI system I started noticing strange things… The first is that it seems to be possible to get VS2015 into a state where it will refuse to load C++ projects.

I now have a real solution to the problem that I outlined on Saturday night and this solution, unlike the one developed during my “Macallan driven development” session on Saturday evening actually works. The problem is that when using code to run build using VS2010 by running a project into devenv.com I get the following error message: C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(214,5): error MSB4175: The task factory "CodeTaskFactory" could not be loaded from the assembly "C:\Windows\Microsoft.

Updated: 12 July 2015 - It seems that this is all incorrect… Upon running my tests again this morning I find that the x64 task runner also fails to run VS2010 correctly and so the environment differences are unlikely to be the cause… So, having decided that my continuous integration system could be better, and having looked at JetBrains’ TeamCity and decided that it doesn’t quite fit I’m looking back at some code that I wrote back in 2008 when I last thought about this kind of thing…

I’ve just spent a day tracking down a bug in a pending release of The Server Framework. It was an interesting, and actually quite enjoyable, journey but one that I shouldn’t have had to make. The bug was due to a Windows API call being inserted between the previous API call and the call to GetLastError() to retrieve the error code on failure. The new API call overwrote the previous error value and this confused the error handling code for the previous API call.

Back in September I mentioned that I had found a problem with my usage of Slim reader/writer locks. I expected this to be something that I was doing wrong but it turned out that it was a kernel bug. This morning Johan Torp tweeted that a hotfix for this issue is now available. The note on the hotfix states: “Note These issues are not obvious and are difficult to debug. This update is intended for applicable systems to apply proactively in order to increase the reliability of these systems.

As I mentioned back in February I’ve been working on a custom video streaming solution for one of my clients. This has been a lot of fun. It was a nicely defined spec using industry standard protocols developed on a fixed price basis with lots of TDD, what’s not to like. The system allows a controlling application to set up RTSP streams for broadcasting to multiple clients. The data for the stream is being transmitted live from one of thousands of smart (IoT) devices and the server buffers this and broadcasts it using RTSP to publish the RTP streams.

We’re pleased to be working with one of our secretive security company clients again to provide a custom video streaming server for them. The server will enable them to record and stream live video from their network of “internet of things” connected devices. As with all M2M and IoT projects this system needs to be able to scale to many thousands of concurrently connected devices and we’re pleased to be able to use The Server Framework’s new Streaming Media Option pack to be able to provide a complete solution quickly and cost effectively for our client.

It looks like the Slim Reader/Writer issue that I wrote about back in September is a kernel bug after all. Stefan Boberg has just tweeted to let me know that Microsoft has confirmed it’s a bug and that a hot fix is in testing.