February 2015

Volume 30 Number 2

Editor's Note - Analyze This

By Michael Desmond | February 2015

Michael Desmond In this month’s issue of MSDN Magazine, Microsoft Senior Program Manager for the Managed Languages Team Alex Turner writes about the new Analyzer functionality in Visual Studio 2015 Preview and the .NET Compiler Platform (known previously by the code name “Roslyn”). His feature, “Adding a Code Fix to Your Roslyn Analyzer,” is actually the second in a two-part exploration of the new Analyzer functionality. The first part, “Use Roslyn to Write a Live Code Analyzer for Your API” (msdn.microsoft.com/magazine/dn879356), appeared in last month’s special issue on Visual Studio 2015 and Microsoft Azure.

There’s a reason we’re running multiple articles on this topic. As Turner notes, the addition of diagnostic Analyzers to Visual Studio 2015 changes the game for developers, enabling real-time feedback about detected code issues as you type. What’s more, Analyzers can provide custom guidance that’s specific to the APIs being used. The opportunities to enable and enforce best practices across the coding environment are hugely compelling, and promise to help eliminate many common flaws and errors that plague code builds today. The Azure Code Analysis package is a case in point. The package provides a set of rules that detect code issues that can impair the scalability, reliability and security of cloud applications.

This is a huge step forward from traditional code analysis, which can only go to work on code at build time. As Turner tells it, the response from developers has been “amazing.” “The community has already built open source Analyzer projects on GitHub such as Code Cracker, which now has over 40 diagnostic rules and over 300 commits. Not bad for a Visual Studio 2015 feature that’s still in Preview,” Turner says.

Helping spur early adoption is the decision by Microsoft to rely on NuGet for package management. Turner says he expects to see dev teams use NuGet not just to download external packages, but to enable private package servers to manage internal libraries. Authorized users can discover these libraries and distribute Analyzers with them.

“Every issue your Analyzer detects is one less e-mail you’ll get from the teams using your libraries, which helps your team save time and focus on development,” Turner says.

One misconception around Analyzers is that developers must be a compiler or language expert to write them. Turner recounts a recent boot camp session where he set attendees off to build Analyzers after a 90-minute talk.

“Within the first two hours, they’d already written 10 meaningful Analyzers, such as one that made sure sensitive information like connection strings or passwords don’t end up in string literals by accident,” he says. “Roslyn makes it easy for every dev team to write custom code analysis that enforces their own coding practices and business rules, well before problems make it as far as a code review.”

For those getting started with the Analyzer functionality in Visual Studio 2015, Turner suggests that developers start simple. Implement a streamlined version of each rule and build it out in increments. The payback will happen quickly, he says, because developers can often catch 80 percent of the cases they hope to snare in less than 100 lines of code.

“Once you’ve got a successful Analyzer that’s squiggling real problems, go ahead and dig in to start catching any special cases you find slipping through,” Turner adds. “Analyzers don’t need to be perfect to start saving your team lots of debugging time.”

Michael Desmond is the Editor-in-Chief of MSDN Magazine.