Recently I published a script pack which calculates code metrics on an arbitrary code snippet. I will later why this is a bit of a stretch. If you don't know what a script pack is, then you should have a look at the ScriptCS project. ScriptCS is about using C# as a scripting language and script packs are ways of encapsulating functionality to make it easy to consume.
At the time of writing this the script pack is still in development, but it is reasonably stable. actually the script pack is fine, it's extremely simple to set up one of those. It's the underlying code analysis assembly (ArchiMetrics.Analysis) that is being finalised. If you find any bugs, then please report them so they can be fixed.
What does it do?
To use it, simply require Metrics:
var tools = Require<Metrics>();
Once you've got that loaded, you can call the Calculate method:
public Task<IEnumerable<NamespaceMetric>> Calculate (params string snippets);
As can be seen, it takes a number of strings. A string can be a code snippet or a file, which will be read. The code is then analysed for: lines of code, cyclomatic complexity, type coupling, maintainability and some other details.
The method returns a Task, because there may be a significant amount of code to analyse, and the world doesn't need to stop while this is being done.
Your mileage may vary
Calculating code metrics is not a simple task and I am just a simple developer, so you are not going to get the same numbers as you would in Visual Studio.
Firstly because I have decided to aggregate metrics based on size (as lines of code). I have always hated how Visual Studio shows that your class has a maintainability index of ex. 94, and when you check the members there are 9 one line members with a maintainability of 96 and 1 with a maintainability of 4. But the horror method is 200 lines long full of spaghetti code.
Another reason for this difference is that the metrics are calculated based on the raw source code rather than the generated IL. The similarity should improve, but since the compiler does a little magic, there will always be a difference. If you ask me, it actually makes more sense to calculate based on the raw source code rather than the IL, because the source code is what the developer has to maintain.
Furthermore I jump through a few hoops to ensure that the code can be analyzed. In a scripting environment the code is not going to come in the same complete package as it does in Visual Studio. For this reason some of the code may need to be rewritten slightly for code metrics to make sense. If you consider the following snippet:
var x = 1;
This is a perfectly valid script statement for declaring a variable in your script context. In Visual Studio this kind of statement would have been a field declaration inside a class. For metric purposes it has to be put into this context, which may require a bit of rewriting.
Finally there is the fact that Roslyn currently doesn't support the async await syntax, which will rule out a lot of new code. But I expect this to change in the next release - whenever that may be.
It's still in beta and will be improved in the future.
The source code for the script pack can be found on GitHub.
The source code for the metric calculation can also be found on GitHub. You'll want to look at the Analysis project.
The script pack is hosted on Nuget.
The same goes for the analysis project.