Question

Is it in anyway possible ( preferably without using any third party libs), to create a function whose type is determined at runtime in C#?

e.g

public static void myfunc(var x)
{
     System.Windows.Forms.MessageBox.Show(x); //just an example
}

NOTE: I want the runtime to determine the type of the parameter and do not want to later cast the parameter to another type, as would be necessary if I use generics. e.g I don’t want:

 myfunc<T>(T x) 
 // and then :
 MessageBox.Show((string)m);

UPDATE:
I am actually making a function parser for my programming language, which translates to C# code. In my language, I wanted the parameter types to be determined at runtime always. I was looking for some good C# feature for easy translation.
e.g
in my language syntax:

 function msg << x
     MessageBox.Show x
 end

needed to be translated to something that didn’t ask for a type at compile time, but would need one at runtime.
e.g

public static void msg(var x)
{
     System.Windows.Forms.MessageBox.Show(x);
}

Answer 1

The keyword introduced for runtime binding in C# 4 is dynamic.

public static void myfunc(dynamic x)

This allows you to make assumptions about x that are unchecked at compile time but will fail at runtime if those assumptions prove invalid.

public static void MakeTheDuckQuack(dynamic duck)
{
    Console.WriteLine(duck.Quack()); 
}

The assumption made here is that the parameter will have a method named Quack that accepts no arguments and returns a value that can then be used as the argument to Console.WriteLine. If any of those assumptions are invalid, you will get a runtime failure.

Given classes defined as

class Duck
{
    public string Quack()
    {
        return "Quack!";
    }
}

class FakeDuck
{
    public string Quack()
    {
        return "Moo!";
    }
}

And method calls

MakeTheDuckQuack(new Duck());
MakeTheDuckQuack(new FakeDuck());
MakeTheDuckQuack(42);

The first two succeed, as runtime binding succeeds, and the third results in an exception, as System.Int32 does not have a method named Quack.

Generally speaking, you would want to avoid this if possible, as you’re essentially stipulating that an argument fulfill an interface of some sort without strictly defining it. If you are working in an interop scenario, then perhaps this is what you have to do. If you are working with types that you control, then you would be better served trying to achieve compile time safety via interfaces and/or base classes. You can even use different strategies (such as the Adapter Pattern) to make types you do not control (or cannot change) conform to a given interface.