4

I need a (very rough) estimation on the lines of code (none-blank, none-comment) of an .net Assembly (c#). Is there an easy way to do this using reflection?

I would prefer a hand-written tool (so I am asking about pointers here...) but I would also settle with a free (as in speech) tool.

The following is my use-case:
I am part of a team, on a not-so-large project having virually no code coverage. We have a report on the coverage which states about 60% coveage (talking about unit-test here.) but this report does not display assemblies that have no unit-tests at all.
So to get the report anywhere near correct I thouhgt I write a small tool that could be called for every assembly without unit-tests (I can find those) and produce an xml like the one produced by our coverage-tool stating that nothing was coverd. As a first approximation for "statements" I thought I count "lines of code".

Nils
  • 9,682
  • 6
  • 46
  • 72

5 Answers5

5

You can't count lines of code using reflection. This information is not available using reflection. Using reflection you can get the signature of class members and you can get the raw IL inside those methods. There is however no way you can effectively translate that IL back to lines of code.

There are several ways to do this. You could (ab)use a tool such as Reflector and call its assemblies programmatically to decompile your assemblies back to C# and do some line counting, or you can harvest information from the .pdb files to get the line numbers. Those program database files contain all that information. There is however no way of reading pdbs using reflection.

NDepend (the tool Gerrie mentioned) uses information from the .pdb files to count number of lines.

But since you are already using a code coverage tool, why don't you add empty unit test projects for the uncovered assemblies and add those test projects to your code coverage tool. This way you can see the total coverage of the whole project. That would be cheaper than buying NDepend and much cheaper than handwriting a LoC counter yourself.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • The first two sentences answer my question great, thanks. Adding empty unit-test is also a good idea. I had something a bit more automagically in mind, but I suppose we could say "every assembly needs (at least an empty) test-assembly" and fail the whole build if assemblies without tests existed.. – Nils Apr 19 '11 at 07:35
4

VS2010 is using Metrics.exe (microsoft). The tool counts lines of code from compiled assemblies. http://blogs.msdn.com/b/camerons/archive/2011/01/28/code-metrics-from-the-command-line.aspx

2

What about using a tool like NDepend instead of writing everything yourself?

Gerrie Schenck
  • 22,148
  • 20
  • 68
  • 95
  • 1
    Because a) I am not sure if I can script that (though I could well try) b) I am not sure if it could produce the xml I needed (though I could well test that) and c) it is not free - neither as in beer, nor as in speech... – Nils Apr 19 '11 at 07:23
  • @Nils: It isn't free, but neither is handwriting it yourself. Of course I assume you get payed for what you're doing ;-) – Steven Apr 19 '11 at 07:30
  • 3
    No so much that it would count ;-) – Nils Apr 19 '11 at 07:44
1

Well, if you are talking about compiled assemblies (as in .dll) then you can't easily get the LOCs from there. All you have is the IL instructions and a single LOC usually results in multiple IL instructions being generated. If you want to roll your own you probably want to have a look at Postsharp which lets you walk the IL and you can count all the interesting nodes but that still leaves you with the guess on how to calculate the LOCs.

Another interesting project might be ILSpy which has a decompiler and can reconstruct the C# source code (approximately). Not sure if it's scriptable however its open source so you can extend it to your needs.

You could also try to extract the information out of the pdb files if they are available. This might be an easier way of getting access to the PDBs

ChrisWue
  • 18,612
  • 4
  • 58
  • 83
  • pdb's are available. So yes - this may be a way, too. Thanks. – Nils Apr 19 '11 at 07:43
  • The actual number of lines of code is not what matters. As long as you have the same method counting historically in order that you can extract some meaning out of the metrics. –  Jun 16 '11 at 20:15
0

Reflection gives you meta data and not lines of code. Instead load the assemblies, find out the classes and modules and give out a statistics saying the following methods/modules are not covered !

Dipti Mehta
  • 537
  • 3
  • 13