Look up the StackFrame class.

Hi,

Can you make the method internal for example?
Maybe if you give more details about your design we can provide a better
approach.

An approach to this problem would probably be to add a member named
likingly to "CanIRunThis" that takes the type of the class calling the
method. It simply returns true if the class type is valid.

NOTE! This is extremely dirty and shows that there may be a design
flaw in your code. You essentially desire different actions depending
on who calls the method. That sounds like polymorphism! Perhaps the
method should be a method inside the calling class, not the callee,
using virtual/abstract/interface, and have them provide the correct
action. Remember, methods are simply a matter of iterating and
processing data. You can seperate the data from the action and pass
the data into the abstract/virtual/interface method in the classes.

So, before you have this:

class MyBiasedClass
{
  // data members
  public void Process()
  {
     // impossible or dirty to check for caller.
     // execute if okay
  }
}

class One
{
  MyBiasedClass mbc; // initialized somehow
  void Process()
  {
     mbc.Process(); // this may do nothing at all
  }
}

// etc.

What if you did this:

class One : IBiasedProcessor
{
   public BiasedProcess(MyBiasedData data)
   {
      // do whatever you need with the data
   }
}

class Two : IBiasedProcessor
{
  public BiasedProcess(MyBiasedData data)
  {
      // do nothing
  }
}

// etc.

The question then becomes, who is responsible for executing the
method. When you start doing things like you're asking about, your
code becomes stagnant and unchanging. If you ever add anything to your
code, you would have to remember to modify the class to accept the new
type. This is a nightmare!

Finally, a slightly easier approach is to create an interface that
acts as a marker. Call is ICanBeProcessed and leave it empty.

interface ICanBeProcessed {}

Any class that supports being processed should implement this
interface.

Then BiasedProcessor.Process() looks like this:

public Process(object myCaller) // object is as simple as it gets
{
   if (myCaller is ICanBeProcessed)
   {
       // execute code
   }
}

Again, that's dirty because you have to use reflection and broaden
your parameter to object. You can make all calling classes
ICanBeProcessed if it supports and CanIBeProcessed method or property
that returns true or false. Then you can get away from reflection and
get a compile time check that all callers are of type ICanBeProcessed.
The problem then is that you are limiting yourself to an interface,
and any type-specific information is hidden unless you do an explicit
cast. In that case, you can either provide more interface properties
or methods to get that data, or you can go to an abstract class.

It is really a matter of how far you are willing to go to make good
code. Some times the best way to do this is to find a way to make the
two classes communicate by passing the caller to the callee as an
abstract instance and calling the needed methods, back and forth.

Try it or try to try it!