Reflection cannot help here, because this is all run time. Reflection can only help you to pull static property of code. Do you even understand that the number of calls can be changed during run time at any moment? [EDIT] As further discussion demonstrated, this is not what OP meant. The problem was failure to explain what is meant by "call". [END EDIT]
It would be completely different story tf you meant to find all references to some method throughout the program, this is much more difficult task. Basically, it should involve decompilation of the code or static analysis of the solution if the source code through parsing it first. I don't even want to discuss it any further here. I you were capable of addressing such problems, I could see it in the way you formulate questions. Sorry. [EDIT] As further discussion demonstrated, this is what OP really meant to do. In this paragraph and in my new comments to the question, I tried to explain why I think this short explanation should be enough for now. [END EDIT]
I would say, there is only one reliable way to count calls: to program it in the calling method itself, increment some counter which is a field of the declaring class. This problem is just trivial. [EDIT] As further discussion demonstrated, this is irrelevant to what OP wanted. [END EDIT]
Bill make some good points in his comments below.
The ability to predict run-time behavior is a big issue of computability theory
The complexity of this problem can be clearly seen on the example of well-known halting problem
: the answer to the question if some program will ever halt or is going to execute forever is statically undecideable
It seems obvious that if that even the halting is undecideable, the prediction of the number of some calls is not better.
From the other hand, let's look at the proof of the halting theorem. The proof is non-constructing and involves the following idea: suppose the halting problem is solvable using some algorithm A. Then it can be proved then the algorithm A can be used to create the behavior of the program opposite the the prediction by A. "Non-constructive" means that the proof does not help to construct the program which behavior is undecideable, but we can see that such design can be more exotic. This suggests that, in many special cases, the behavior of program would be quite predictable.
Of course, this is true, so Bill is right here. The practically important problem here is: can a class of predictable programs be found, which would be non-trivial enough (that is, good enough for solving practical non-trivial problem) and could static analysis be practical. The problem is very difficult, but static analysis is already used to validate certain aspects of run-time behavior of a program statically. I'm actually working at one of such problems.
But of course, as now we know that Nathan meant a very different problem: to could the number of call statements which program the call to a certain method, in the body of some other method. This problem is solvable, because this is a pure static analysis, not directly related to the run time. I'm too lazy to get to solving it; perhaps Nathan can find a correct solution based on the one he already posted.