You would either need to do it on the source code itself using the C# parser or do it after the fact on the binary using reflection, etc.
In reality though, its impossible to cover all the cases. There are lots of different ways to call a method that you would be hard pressed to pick up on using either the C# parser or reflection. I.e., I can call it directly, through a delegate, through reflection, through expression trees, through a lamba expression, etc.
Your best bet to be completely fool proof is to have a check in the method itself.
One problem I would run into is that there may be intermediate method calls of various signatures before the call is finally made to my method. If I want to go the regular expression route, I would need to know all those signatures as well, which are added, edited or removed throughout the project.
I'm not sure there is an easy way to do that, but that doesn't mean it's impossible. Here is one way to go about it.
You'll need to create a post-build event to call your code that inspects the assembly.
The code to inspect the assembly will first have to load up the just-built assembly. You can then get a list of all the types in that assembly (see here).
Next, you'll need to inspect the methods on each of those types:
publicvoid InspectMethod(MethodInfo mi)
var body = mi.GetMethodBody();
var ilBytes = body.GetILAsByteArray();
// TODO: inspect the ilBytes.
The only way I can see to check calls to your method would be to manually inspect the IL. That's the part that I don't think will be easy, but it should be doable. You can read about that here: "Parsing the IL of a Method Body".
This sounds like a big pain in the rear, and I can think of very few scenarios where this would be necessary or even useful. Perhaps if you let us know what you're trying to accomplish by doing this, we could suggest another way.
Ah. A little contextual information goes a long way.
So you want the parameter to be unique when statically looking at your source code: each location where SignalError(int number) is called, number will be a constant and has to be different.
This is what I would do:
- assume all source files are in a single folder and its subfolders (and no unrelated files are there);
- create a little app that enumerates, then reads those files (use the 3-parm overload of Directory.GetFiles)
- look for lines that hold the method name, extract the numeric parameter, and add it to a Dictionary; this will throw an exception when the key already exists, i.e. when the number has been entered earlier.
I was thinking if I could get a start, I could figure out the rest.
But, I mislead with my simple example.
There will be levels of method calls between mine and the point in code where the unique error number is supplied.
So, it won't be a simple check for calls to my method because those calls in turn will take a variable error number (but, the error number always tied to exactly 1 line in code).
public void TheMethod(string sMessage, int iTheUniqueErrorNumber)
public class T
public void ErrorOccurred(string sMessage, int iTheUniqueErrorNumber, int iCallerID, ...)
public void DoSomeWork()
// Some error occurs
ErrorOccurred("Blah blah blah", 2345, this.ThreadID, ...);
// Some other error occurs
ErrorOccurred("Blah blah blah", 2346, this.ThreadID, ...);
OK, so if the number of related methods (such as ErrorOccurred) is rather small, you could still make a list ("intermediateCallers") of them; you could do this either manually, or by generating a list of all methods calling TheMethod with a variable error number, not a constant one (you would have to make sure the list is good!).
You could then search all code for calls to either TheMethod or any method in intermediateCallers; parse the error number (I know, the method signature may vary, you have to teach your utility that); if it is a variable one, hope or check you are inside an intermediateCallers method; if it is a constant, check it in your Dictionary.
For creating a setup CD for this application, pre-requisite is required for the .Net framework.
For example the default ticked is: Microsoft .net framework 4 client profile (x86 and x64)
Should I also tick Microsoft .net framework 4 (x86 and x64) ?
It's not needed unless you want to make them install the entire framework.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997