I tend to develop code with JITT (Just in time testing), this is like TDD when I’m doing it but it doesn’t always get done. What does get done, generally, is the “first test” for each class. This ensures that subsequent testing is possible as the code doesn’t have hidden dependencies and it gives me a test harness that’s ready to go when I find that I need it. More complex code end up being TDD, easier bits end up as JITT where the tests are only written when I’ve wasted time banging my head on the desk trying to debug problems the “old fashioned way”.
So, it’s nearly a year since I first started noticing issues with VS2015 on my build servers. The bug in question now has an entry on Microsoft Connect and Google can help with some work arounds which don’t require turning the machine off and on again a random number of times until it works… There’s even a Visual Studio extension that fixes the issue for you (!).
I find it disappointing that this hasn’t been fixed, it’s a fundamental usability issue which seems to be causing lots of people lots of pain.
I’m looking at adding support for the TLS Application-Layer Protocol Negotiation Extension to The Server Framework as a precursor to looking into HTTP 2.0 support. This TLS extension is supported by both SChannel and OpenSSL. It’s relatively new (only having been included in SChannel since June 2014 (!)) but there seems to be no documentation on MSDN for the structures and how to use them to add the appropriate entries to the TLS handshake and then to select and validate the protocol of your choice… Searching today with Google for something like “SEC_APPLICATION_PROTOCOL_NEGOTIATION_EXT” just gives just the usual selection of hits to people who think it’s clever to run the Windows header files through their document generators and then publish the results on the web…
There should be a Developer Advocate position within Microsoft. They seriously need someone who doesn’t “Drink the Kool-Aid” who can step in and tell the Program Managers or Marketing bods or whoever it is who makes all the really STUPID decisions that the decision is stupid and that they should get back in their box and leave the developers who support the Windows ecosystem by building software that runs on it to just get on with their lives…
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.
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.
Today I discovered that C++ scoped static initialisation (function level) in Visual Studio is not done in a thread safe manner. It’s the kind of thing that I should have already known but I guess I assumed that since namespace level static initialisation was safe so was function level static initialisation. Unfortunately it’s not. If you read the MSDN documentation in a particular way you could decide that the docs say that it’s not; but it’s imprecise and unclear and I doubt that I did read the MSDN documentation anyway.
I’ve been pretty happy with moving to Windows 8. I’ve got used to the “new” UI, it was a pretty painless transition once I learned the new shortcut keys and I actually think that the new “start menu” is better, you don’t have to worry about complicated trees of folders, it’s all flat and you just start typing the name of what you want… So for me, a developer with two monitors and no touch interface using the desktop pretty much as I always have done, Windows 8 works well.
There’s a gnarly networking question on stack overflow that I’ve since reposted on various Microsoft forums and so far I’ve had absolutely no useful response. Not even an “I don’t know, but I’ll look into it”.
I can understand that, perhaps, the issue may be a little bit technical for a support person who isn’t steeped in networking API knowledge; but where are the MVPs? Why isn’t there a Winsock MVP who can tell me that the bug has already been raised somewhere and might get fixed, or that it’s a known and desirable breaking change?
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The WebSockets protocol includes a way for the endpoints to shut down the connection.
If an endpoint receives a Close frame and that endpoint did not previously send a Close frame, the endpoint MUST send a Close frame in response.
