I recently installed Visual Studio 2012 on my desktop; now I have Visual Studio 2008, 2010, and 2012 installed. I will likely continue to work in Visual Studio 2010 for projects like BASeBlock, but I still want to try out the new features of C# 5.0, as well as become familiar with Visual Studio 2012 itself.

First, I ought to say something about Visual Studio 2012. It has gotten a lot of flak for things like the all caps menu and the use of monochromatic icons. I agree with the all caps menu being a bit, well, off- but the monochrome icons I didn’t even notice. I thought about it this way- I couldn’t tell what the heck half the icons in most programs mean with colour. Removing the colour doesn’t make it harder to tell what it is because I couldn’t tell what it is anyway. Most of the information about what a toolbar button does is the tooltiptext, with the exception of the obvious ones (save,open, copy,paste, etc). In the spirit of it, Pictures are worth a thousand words. Let’s compare the two, running on my Windows 7 Machine.

Visual Studio 2010. Here we see BASeBlock.

I’ll be honest, I’m usually late to the party. By the time I’m using an IDE, most people have moved on. With VS2008 this was the case; VS2010 was out already. I only started using 2010 recently- but on the bright side it was “current” at the time for production software since 2012 was not released. Now that 2012 is released, I’ve started to use it as well. Well technically I used it before it was released in RTM form- (being a MVP has quite a few advantages when you are willing to ride the bleeding edge), but until recently I wasn’t allowed to, if I understood the NDA correctly, post too much about it. Now that it is released though legal obligations to that accord are no longer applicable (I hope that is the case, I’m sure they will let me know if that is not the case). The main difference we see between these screenshots- aside from the fact that they are looking at different projects, obviously- is that 2012 uses capitals for the menus. Now I’ll be honest, This sort of seems silly to me, I cannot really think of why they decided to do this. It doesn’t make a huge difference, really, it just feels- odd. The other difference is that icons are more monochrome, which I personally didn’t notice, and don’t think is as big a deal as everybody seems to be making it seem. I keep seeing mailing list postings exclaiming how this “ruins the user experience”. In my opinion the fact is that you couldn’t really tell what half the icons did at a glance anyway- so you usually have to look at the tooltip to figure out what it is for, and from then on you simply memorize what the abstract images mean; there isn’t really anything intuitive about them, and the only reason most of us can easily identify icons such as cut copy and paste is because we became used to them; the Save icon is a good example, it’s still typically a floppy disk, and in 2012 (the year, not the version of the VS IDE) I’d be hard pressed to find a system with a floppy drive, let alone people who use them. I’ve got JetBrains ReSharper installed in each; I think they deserve commendation since they actually had a VS2012 version out before it was even released. This might also reflect the compatibility between the different versions of the extensibility framework, too.

Visual Studio 2012 IDE. Here we see BCSearch.NET. Or, rather, the beginnings of what might become BCSearch.net.

Obviously, the entire visual style has been tweaked; but this is no surprise; there is a similar disjunction between Visual Studio 2005 and 2008 and 2008 and 2010 as well. Personally, I have to say I like it. Some of the biggest differences I noticed are that Visual Studio 2012 actually runs better than 2010; 2010 pretty much destroys my laptop as far as usability- but with 2012 I’ve actually forgotten I had it open at all. The installation had two reboots, which is twice as many as I think ought to be needed, but no matter. A much larger feature change- and something that goes toward the functional end of the spectrum- can be found in the language features added to the .NET languages.

Naturally, as a C# developer, my main interest is with features added to C#. One of the biggest features is first-class language support for asynchronous methods, in the form of the async keyword, and the await keyword. In many ways, you can think of these as facilitating coroutines, much like yield return and yield break, but rather than dealing with Enumerators, these deal with “Tasks”. When you call an asynchronous method, it returns a Task object. Either a Task object, or a Task object, where T is the “return value” of the routine. The idea being that as a the client of that function, you can use the returned Task object to monitor the function’s asynchronous execution.

You might be expecting me to “school” you on the use of these new keywords. But to be honest, I don’t think I really understand them well enough to teach their usage. What I will discuss is the fact that my testing program that I made to experiment with the feature has turned into what can essentially be considered a start to rewriting BCSearch in C#, which I’ve been meaning to do for a while. The ‘original’ BCSearch was written in VB6, and sort of fakes asynchronous operations. It has quite a few bugs and issues that I’ve never gotten around to fixing, but overall suites me for the odd search. However, it is still written in VB6, and I feel a lot would be gained by a switch to C# and .NET; even just Windows Forms, which is what I’ve done.

The new BCSearch.NET is implemented by the use of DirectoryInspector classes; each one only inspects a single folder, spawning a new DirectoryInspector to inspect any subfolders, and raising various events. Each DirectoryInspector monitors it’s “child” inspectors, making sure they are all finished before it fires it’s own completion event. The “magic” is that each DirectoryInspector’s inspection routine is run asynchronously as an async method, letting the UI thread of the program carry on.

Of course, such a method would be perfectly doable using Threads, but what asynchronous keyword support in the language allows for is far less boilerplate and management code and more code being written for actual program logic, which can be seen only as an advantage. The only downside being that one has to understand the async keywords and how they interoperate and work together first, which in many ways requires at least some basic understanding of how this sort of feature would be created using standard Threading techniques.