Compiler As a Service (CAAS) for VB.NET

Microsoft has been promoting a futures feature of its .NET compilers called Compiler As A Service(CAAS). CAAS will allow direct access to the functionality of the compiler. From a Microsoft job posting described here CAAS allows “REPL, write-your-own refactorings, C# and VB as scripting languages, and taking .NET to the cloud”. I think VB.NET, in particular, stands to gain with the potential to have C# code be convertible to VB.NET.

“Tightening the feedback loop” has been my mantra over the past year. In just one sense of this phrase, REPLs (read evaluate print loop) are a way to get immediate feedback on your code. I have been using, and loving, LinqPad a lot lately. It is far more than way to perform Linq queries. It is a very well thought out code snippet compiler. It isn’t truly a REPL, code is compiled with the benefit of behind the scenes code that LinqPad provides to make a complete class library. Also, unlike a REPL, once code is run, its variables aren’t treated as globally available for continued use. Essentially it is read-evaluate-print without the loop. Linqpad does succeed in providing much quicker feedback. Besides LinqPad, PowerShell and the Firebug for Firefox Javascript commandline are things I use frequently.

Aspect-oriented programming with tools like PostSharp could be greatly enhanced by CAAS. Postsharp works as a post-compilation code weaving. I think it might be significantly easier to weave code with the compiler functionality opened up. The job posting suggests that Refactoring processes could benefit on the other direction as a mini-compilation step done in the background to assist in changing the codebase. I wouldn’t want to speculate how though at this point.

As a LinqPad user in VB.NET you are a second class citizen since Intellisense is only provided for C#. Joe Albahari articulates on stackoverflow that CAAS would allow him to more easily provide VB.NET intellisense.

Putting a VB.NET specific spin on CAAS, is the potential ability to seamlessly convert between VB.NET and C#. One of the obstacles facing VB.Net is the necessity of converting code snippets available only in C#. For example, trying to convert a C# Linq statement to VB.NET fails utterly using Telerik’s converter, http://converter.telerik.com/. This will help a real pain point in using VB.NET.

Nesting Depth Metric

One of my fundamental coding practices is to avoid nesting depth in methods. A really good explanation of this point has been made by Patrick Smacchia, author of NDepend. NDepend, speaking as a purchaser of the product, is a very cool tool for measuring an application. I won't belabor the technique, since Patrick explains it well, but I just want to stress it because I think it so critical. I call this the early exit strategy. Rather than have nested if statements, I return from a function as soon as possible. So, instead of having a more complex boolean statement or nested ifs, I would have a simpler expression with two if statements, each of which would return from its function if appropriate. As Patrick shows, this also applies to a continue statement, to abort further process on the current iteration of a for loop.

NCover and working with Code Coverage tools

I have been reluctant to embrace TDD philosophy in my development. I have spent the last year with a philosophy of adding unit test after coding done with DI techniques. The tests were aimed at the “low hanging fruit” scenarios. These included lower level classes with fewer dependencies and logic centric classes. Dependencies like communications, file I/O, and timing based events were classes that tended to be ignored. Not surprisingly my defects were focused in areas not covered by tests. I did employ a practice of writing at least one unit test for each defect.

Recently, after getting encouragement from management to spend time improving unit tests (in part due to schedule slack), I spent some time working with NCover, one of the leading .NET code coverage tools.

NCover has been simply excellent to work with. I have used NCover 3 complete which, at $479, is pretty pricey. NCover 3 classic is reasonably priced at $199. The features provided by the classic level, suit my current usage fine. The quickstart documentation is emphasized by the UI presentation for new projects. The focused ribbon-based UI made it easy to navigate. I found it to be a nice workflow to move between production code viewed in NCover and test code viewed in Visual Studio. For me, I tend to open many documents in Visual Studio at once, and not having to bounce between test and production code files in Visual Studio helped me be more productive.

I spent some time later working with Visual Studio 2010 Code Coverage (available with Premium or Ultimate editions). I think it important to mention my development environment might well affect my perspective. My machine is modern but lacks a solid state hard drive. Visual Studio does crash or hang more than I would like. Visual Studio is also kinda slow and uses lots of virtual memory. I have never met an Add-In that I didn’t want so, so this could well be affecting my experience. These factors collectively encourage me to favor non-integrated tools. More importantly, my single monitor and 1024x768 display really limits my desire to minimize the number and size of visual studio windows open.

Having given these caveats, I strongly preferred my experience with NCover. First, my above issues with Visual Studio make it feel cramped as it is. Second, debugging MSTest unit tests and obtained code coverage are mutually exclusive. I can have on or other turned on at any given time. Hitting Control-R Control-A to debug into unit test is where my sweet spot for working with tests is. I really don’t like the idea of having to switch settings regularly. Third, NCover’s windows and icons are tightly focused on its core tasks. This has helped make learning NCover really easy. In contrast, Visual Studio leverages its existing code editor, status windows, menus, and icons. Using Visual Studio Ultimate, the code coverage-related options are scattered amidst a plethora of features. Fourth , VS requires instrumenting assemblies whereas NCover doesn’t. Since my assemblies are usually signed, this means the assemblies must be modified and then re-signed for each coverage run.

Thanks to attendees of my Introduction to Linq as a Language Feature talk.

Here is a LINQ to a zip file with my presentation and all sample LinqPad files.

Here are a set of LINQs covered in the talk.

• Test what you have learned about LINQ by taking the LINQ quiz!


• LinqPad, a wonderful tool used heavily in this talk.


• A really lucid explanation of grouping in LINQ


• An explanation of common gotcha with Linq, and really .NET in general, is the need to implement GetHashCode to deal with an equality check . This is a good example of the pain that you can go through, but take this lesson: implement GetHashCode!


• This is a nice explanation of how to deal with the possibility of an IEnumerable that contains no elements. Stack Overflow has many great LINQ questions, often answered by Jon Skeet. An excerpt from this post is "Use First when you know that there is one or more items in the collection. Use Single when you know that there is exactly one item in the collection. If you don't know those things, then don't use those methods. Use methods that do something else, like FirstOrDefault(), SingleOrDefault() and so on."


• An excellent book, Linq In Action has code samples that plug in directly to Linqpad.


• Hooked on Linq offers a brief introduction to LINQ. The author also has written a book Linq to Objects Using C# 4.0.


• Microsoft has published 101 LINQ examples.


• You can't research LINQ much without running into Jon Skeet's work. He has a new training series on C# at Tekpubthat takes a gentler approach. Beyond that, if you really want a deep understanding of C# features and LINQ. This material, particularly his blog and presentations, can be rather challenging. If you are up for the challenge, I have found it to be very rewarding.


• The Interactive LINQ project from Microsoft is still in an early stage but is worth checking out. Here is an overview of the project.


• LINQ can be considered a pull technology like most database access approaches. Microsoft has provided a set of Reactive Extensions that provide push technology, kind of like SQL Server Query Notifications.


• If you'd like to read more about LINQ to WMI, here is my codeproject article.


• Here is a helpful presentation on closures by Stuart Langridge. It is in Javascript, but the sample concepts apply.


• Linq perspectives from Bart De Smet.