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]

[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*:

Please see:

http://en.wikipedia.org/wiki/Halting_problem[^],

http://en.wikipedia.org/wiki/Computability_theory_(computer_science)[^],

http://en.wikipedia.org/wiki/Undecidable_problem[^].

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.

--SA

The current solution would be to right click methodB in VS and find all references that gives me the count I'm looking for. I wanted to skip having to manually count references.

not a number of calls at all. I addressed this problem in the second paragraph of my answer. I'm just curious: did you vote 1 because you failed to see it? I simply don't want to discuss this really different problem with you any further, at least right now.First, this problem is really difficult, so my introductory paragraph in my answer is enough. More comprehensive answer will need a really big article with code, etc. This is something well above the format of

QuickQuestions & Answers.Secondly, please forgive me if I'm wrong, but I think this problem is well above your head. I can see this looking at the way you ask questions and argue. Of course I would be happy to be wrong here.

If you did, I take my words back with my pleasure. Impressive.

Well, even though the code does not work as you require. As I say, it is not possible to count the number of calls in general case. Please see my comments to your solution.

Cheers,

--SA

--SA

What you say implies, to me, that you can know exactly at design-time precisely how many times MethodB references exist: unless you are in a very strange situation ... which I cannot even imagine ... where somehow you do not have access to some design-time code being generated by some ? that defines additional references to MethodB.

In my comment (see above), I explained why I don't want to get into further detail.

--SA

... and: whatever actual scenario you are dealing with here: a concrete example to help us help you ?

Are you talking about the number of calls to a given method, from anywhere in some arbitrarily complex application composed of any number of classes which may be static, or: non-static classes made instances once at the program's start ... or: non-static classes, with instances created any possible number of times during the program's use ?

Imagine I write a program to calculate a fixed number of integers in the Fibonacci program: yes, then I can easily know exactly how many times the method to compute the next number is called: but that's not the way programs are written, and that is a fool's example whose only purpose is not to "mock you," but to try and get you to clarify what you are speaking of.

What happens when you have a public method in a static class that may be called by any number of libraries which are added as references (compiled as .dll's) to your project ?