.NET in SonarQube: bright future
A few months ago, we started on an innocuous-seeming task: make the .NET Ecosystem compatible with the multi-language feature in SonarQube 4.2. What followed was a bit like one of those cartoons where you pull a string on the character's sweater and the whole cartoon character starts to unravel. Oops.
Once we stopped pulling the string and started knitting again (to torture a metaphor), what came off the needles was a different sweater than what we'd started with. The changes we made along the way - fewer external tools, simpler configuration - were well-intentioned, and we still believe they were the right things to do. But many people were at pains to tell us that the old way had been just fine, thank you. It had gotten the job done on a day-to-day basis for hundreds of projects, and hundreds-of-thousands of lines of code, they said. It had been crafted by .NETers for .NETers, and as Java geeks, they said, we really didn't understand the domain.
And they were right. But when we started, we didn't understand how much we didn't understand. Fortunately, we have a better handle on our ignorance now, and a plan for overcoming it and emerging with industry leading C# and VB.NET analysis tools.
First, we're planning to hire a C# developer. This person will be first and foremost our "really get .NET" person, and represents a real commitment to the future of SonarQube's .NET plugins. She or he will be able to head off our most boneheaded notions at the pass, and guide us in the ways of righteousness. Or at least in the ways of .NETness.
Of course it's not just a guru position. We'll call on this person to help us progressively improve and evolve the C# and VB.NET plugins, and their associated helpers, such as the Analysis Bootstrapper. He (or she) will also help us fill the gaps back in. When we reworked the .NET ecosystem there were gains, but there were also loses. For instance, there are corner cases not covered today by the C# and VB.NET plugins which were covered with the old .NET Ecosystem.
We also plan to start moving these plugins into C#. We've realized that just can't do the job as well in Java as we need to. But the move to C# code will be a gradual one, and we'll do our best to make it painless and transparent. Also on the list will be identifying the most valuable rules from FxCop and ReSharper and re-implementing them in our code.
At the same time, we'll be advancing on these fronts for both C# and VB.NET:
- Push "cartography" information to SonarQube.
- Implement bug detection rules.
- Implement framework-specific rules, for things like SharePoint.
All of that with the ultimate goal of becoming the leader in analyzing .NET code. We've got a long way to go, but we know we'll bring it home in the end.