Some bits of code:.
C# version of IsNumeric( ) :
public static bool IsNumeric(object value){
   try    {
      int i = Convert.ToInt32(value.ToString());
      return true;
   }
      catch (FormatException)    {
      return false;
   }
}[via The Wagner Blog]

Actually, this doesn't really do what IsNumeric does, as IsNumeric should also return true for floating point numbers.  This is really more of an "IsInt".

 

Also, why write your own?  You can just reference Microsoft.VisualBasic.dll, then do the following:

if (Microsoft.VisualBasic.Information.IsNumeric("5"))
{
 //Do Something
}

The VB one actually performs better, as it doesn't throw an exception for every failed conversion.
[Sean 'Early' Campbell & Scott 'Adopter' Swigart's Radio Weblog]

What's REALLY interesting is what's going on in the Source Code (disassembled) for the VisualBasic.Information.IsNumeric (as I am trepidacious to include this dependancy (dunno why) in my code). 

Looks like it's pretty much the checking the Type of the object via iConvertable or the alternate TryParse...:

public static bool Isumeric (object Expression)
{
bool f;
ufloat64 a;
long l;

IConvertible iConvertible = null;
if ( ((Expression is IConvertible)))
{
   iConvertible = (IConvertible) Expression;
}

if (iConvertible == null)
{
   if ( ((Expression is char[])))
   {
       Expression = new String ((char[]) Expression);
       goto IL_002d; 'hopefully inserted by optimizer
   }
   return 0;
}
IL_002d:
TypeCode typeCode = iConvertible.GetTypeCode ();
if ((typeCode == 18) || (typeCode == 4))
{
    string str = iConvertible.ToString (null);
   try
   {
        if ( (StringType.IsHexOrOctValue (str, l)))
   {
        f = true;
        return f;
   }
}
catch (Exception )
{
    f = false;
    return f;
};
return DoubleType.TryParse (str, a);
}
return Utils.IsNumericTypeCode (typeCode);
}

internal static bool IsNumericType (Type typ)
{
bool f;
TypeCode typeCode;
if ( (typ.IsArray))
{
    return 0;
}
switch (Type.GetTypeCode (typ))
{
case 3:
case 6:
case 7:
case 9:
case 11:
case 13:
case 14:
case 15:
   return 1;
};
return 0;
}

Chris Brooks, my CTO, and I finally sat down to spend what we thought would be some serious time with Microsoft Office 2003's InfoPath and Chris Anderson's BlogX (Chris and some managers run BlogX internal blogs). 

We started up InfoPath, selected "New from Data Source" and pointed it at Chris's Internal Blog's WSDL.  We hooked up the CreateEntry Document to the CreateEntry Operation, and were presented with the Design View.  Rather than dragging one simple element at a time, we guessed and drug the whole CreateEntry and *poof* the form was sitting there.  We stared...exchanged "Oh, that was sweet" and continued.  We added name and password, a submit button and saved. 

We started up the Data Entry view, filled out the form, and nothing bad happened.  Suspicious thoughts filled the air, but we supressed them and visited Chris's blog...and dammit if the thing wasn't updated with our new entry.

As we sat and stared, I thought about the stacks of protocol layers and specificiations that we sat atop.  The false starts, the iterations, the consortiums, the presentations.  I thought of the day I first installed Trumpet Winsock on my Windows 3.1 machine and telneted to cdconnection.com, content to send my credit card number screaming in plaintext across the open Internet. 

The view from here is lovely.  I look forward to the things I can build with the things that have been built for me.