.NET Developer Tooling: The Roslyn Revolution

Unless you’ve been on holidays for the last week on an island without internet,  you’ve probably heard that Microsoft announced that Roslyn is now available as Open-Source.

Roslyn is the next C# and VB.NET compiler, developed with these languages. It is not just a compiler but also provides an extensive set of APIs to do plenty of interesting stuff on source code including, intellisense, refactoring, static analysis, semantic analysis… This paradigm is called Compiler as a service.

Until now (I mean until Roslyn will be integrated in VisualStudio) the offer proposed by Visual Studio concerning these areas was pretty limited. If you need more than basics (in other word if you are a seasoned pro .NET Developer that value its time) you are certainly using daily Jetbrains Resharper or DevExpress CodeRush. But with Roslyn finally becoming a reality, these two well established tools teams are facing a dilemma. To use Roslyn or to not use it??!

A risky decision must be taken

  • Don’t use Roslyn, and take the risk that the Roslyn revolution will challenge the leading position. Another risk, more subtle but it’ll be very noticeable, is that Visual Studio will host in-memory the Roslyn infrastructure. So not using Roslyn will result in asking users to host two compiler/analysis infrastructures in its VS process. This will have a crucial consequence on both memory-consumption and performance. Not using Roslyn is the choice of the R# team and I am worried a bit since I am a big fan of R#.
  • Do use Roslyn, and take the risk to spend a massive refactoring effort for at least one release cycle, effort that could be spent on new features to increase competitiveness. Also, while Roslyn have been developed by some of the smartest brains on earth, it might not be suitable for doing everything. R# developers are claiming that their solution-wide analysis is not really doable with Roslyn. But investing into such huge refactoring is the choice of the CodeRush team. One important advantage with relying on Roslyn is that CodeRush will have future language features almost for free. This can pay off over the long term.

While my preference goes today to R#, it is likely that in five years from now, there will be one leading tooling built upon Roslyn, to achieve all these goodies (refactoring, analysis…). Will it be:

  • A VisualStudio extension developed by Microsoft. I have no idea if such project exist but it’d make sense. At least a partial product must be actually developed I guess.  A partial product that is not trying to implement all what CodeRush or R# can do, but at least increase substantially the actual basics  provided by VS out-of-the-box today.
  • CodeRush
  • A VisualStudio extension developed by a third company, we haven’t heard about yet.

Also we must take account that CodeRush and R# are actually super-mature products. Both teams are taking high risks for the future and it is not clear that another product (developed by the VS team or another team) might one day achieve such level of maturity.

Concerning NDepend

NDepend has never been meant to compete with CodeRush nor R#. Some few features overlap, but many NDepend users are also using CodeRush or R# (like me actually).

NDepend is super-optimized to do macro-analysis. It does check hundreds of solution-wide code rules per second, while CodeRush and R# can do solution-wide checks, but more like in a matter of minutes on real-world large code base.

CodeRush and R# are brilliant to achieve micro-analysis, like showing to the user within the code editor that something can be improved in a method body. NDepend touches some of these areas, but a tool like CodeRush or  R# prove to be invaluable to obtain smart advises in all situations. And they come with the wonder of refactoring.

NDepend offers the necessary ten-thousands foot perspective, in order to take the most relevant refactoring decisions, like about what to do to make a component more cohesive, more re-usable, less coupled, less spaghetti-like. CodeRush and R# are excellent to actually achieve the refactoring once a decision has been taken.

Also, NDepend lets write custom code rules through LINQ queries. I believe our API, for that matter, is close to optimal. For ruling that Base class should not use derivatives it is as easy as writing:

No need to create a VS project. No need to click a compile or run button. Result is well formatted, well browsable and live updated if the rule gets edited. Such rule is executed in a few milli-seconds, even against a very large code base. And could the syntax be more concise? (thanks LINQ, thanks fluent API).

In addition NDepend has many other useful features out-of-the-box including code visualization (matrix, graph, treemap), code diff/baseline, code trending, reporting, code metrics including code coverage, tons of smaller-scale facilities to perform all sorts of convenient action… and many others features are in the development pipe. None of them really overlap with what other tools offer.

I went through all this description to say: NDepend is living in its own niche-area. So far it cohabits gently with CodeRush and Resharper and it doesn’t consume much extra memory nor extra performance. My opinion is that NDepend will cohabit well with Roslyn, without the need to be rebuilt upon it. If you don’t really agree with this, we’d be glad to hear your stance.

Posted in CodeRush, Compiler Service, LINQ, NDepend, Resharper, Roslyn | Leave a comment

Extending Splunk’s search language with custom search commands.

I recently blogged on a feature which I worked on, custom search commands for Splunk in our Python SDK. Custom search commands allow you to extend Splunk’s search language with new commands that can do things like apply custom filtering, perform complex mathematical calculations not in the box, or generate events dynamically from an external data source like an external API. Currently we only support them in Python but we’ll be adding more languages in the future.

In the first post of the series I talk about how to build a simple generating command.



Posted in splunkdev | Leave a comment

Oh XAML, how I hate your error messages

I like XAML, I like some of the cool things I can do with it (although I do wish it was more like CSS in some ways). However, for something that has been around since 2006 why do your error message suck so bad and provide so little information.

Recently while making a very benign change to one of my resource files I received the following error when I launched my Windows Phone 8 application in the emulator.AccessViolationError

Of course I was stumped by this, in fact in my 4+ years of working with XAML I can honestly say that I never remember seeing this error. To try to resolve the issue I did what any good developer would do, stop the app and try again… It still happened.

Next, I thought maybe the emulator vm was screwed up so I killed the emulator and restarted… It still happened.

Ok, I knew it had to be something I did so I started diff’ing all the files I have changed to see if I could find what is causing this, fortunately for me I had only changed a few files and most were resource files. Immediately I noticed the issue, I had fat fingered something in my resource file, see below.

Notice how at the end of my line I had added an inadvertent slash at the end, yea this was my issue. So it turns out that invalid markup will give you the error mentioned above… WTF, really? Why is this not some sort of parse error?

I would totally have expected to get a parse error with the EXACT line number the error occurred, not some obscure error about memory. #Fail

Oh well, I should have known better I guess.

Till next time,

Posted in Windows Phone | Tagged | Leave a comment

How does TypeScript help prevent bugs in JavaScript

JavaScript is an awesome language once you grasp its power and its features. However, like all dynamic languages simple and stupid bugs can creep their way into your code if you are not careful. Many times this happens because types change over type but since JavaScript is dynamic it is really, really hard to detect these changes in an enterprise scale application.

TypeScript helps to solve this problem by providing compile time Type checking. This compile time checking can be used to generate type symbols on your code and alert you, via build errors, when you introduce a simple bug.

Take this code below for example of what I mean

Do you see the error? Look carefully, it is there?

Give up? Image blow has it pointed out

Since I am using KnockoutJs here and trying to set a value on an observable I cannot set the value this way.  I need to set it via method notation.

If we were to add typing to our code as below we would immediately be notified there was an error rather than at run time.


Notice how once I added the typing information to the code the TypeScript compiler was able to tell you that you have a issue in your code, red squigglies and all.

Once we fix our code, as seen below, we are golden.


Now I am not making the claim that TypeScript will fix everything. What I am saying is that by introducing typing into the code and allowing that typing information to flow through your code you will potential to create cleaner and more stable code.

Till next time,

Posted in TypeScript | Leave a comment

Sublime is Sublime 12

OK so we are at the last blog post in the sublime series. I have I hope saved the best one for last. One of the largest questions I have received during this series is how do I get intelisense and that R# is awesome because it supports things like goto definition and rename…

In this post we will add all of these features to sublime. There is a great project out there called OmniSharp that supports most of them (and in the future can support many many more!). Let’s get going then and add our sublime support.

https://github.com/moonrabbit/OmniSharpSublime is the project

So to install:

goto your packages directory (linux here so it may be different in windows or mac, just look in packages in sublime to find the folder)

cd ~/.config/sublime-text-3/Packages/
git clone git@github.com:moonrabbit/OmniSharpSublime.git
cs OmniSharpSublime
git submodule update --init 

Now you have gotten all the needed files. The next thing we will need to do is build OmniSharp


Now edit your project file for sublime and add at the root level

 "solution_file": "./EventStore.sln"

Remember the path is relative from your project file! restart sublime if its running. Try typing out variable names and you will see you have intellisense. If you hit a . you will notice that it does not come up :( by default the auto complete keystroke is alt + / you can remap this to ctrl+space if you want by editing your keymap in sublime.

Want to go to definition of a method? Try f12 by default (again can be remapped its up to you!)

In the next post we will recap everything that we have done so far!

Posted in Uncategorized | Leave a comment