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.
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.
I’ve been a big fan of Gimpel Lint for years. It’s a great static analysis tool for C++ and it can locate all kinds of issues or potential issues in the code. My problem with it has always been that it’s a bit of a pig to configure and run, more so if you’re used to working inside an IDE all the time. Several years back I had some custom Visual Studio menu items that I’d crufted up that ran Gimpel Lint on a file or a project and some more cruft that converted the output to something clickable in the IDE’s output pane.
I’ve been working on some code for a client recently that needs to run in a multi-threaded environment. Unfortunately it was never really written with that requirement in mind, or, more likely, the people who wrote the code knew that it needed to be accessed from multiple threads but didn’t really understand quite what that meant. As such I’m doing some fairly hairy refactoring for them. It’s high risk as there are no unit tests and the budget doesn’t really extend to completing the work, let alone “spending extra time” writing unit tests… The code is written in quite a ‘C’ style, most things are simple structs and most data is public and as such member functions fall where they are most conveniently written.
This article over on Preshing on Programming looks useful. It gives a step by step guide for building GCC cross-compilers, I expect it will save me lots of time at some point in the future.
