I'm going to do something unfair to make a point: int.TryParse versus DWC.NumberUtilities.
Note this is a completely unfair test because Whidbey is in Beta and all, but I'll throw it out there anyway. I went ahead and tested the original TryParseInt method (the completely unoptimized version that has been deprecated in the utility), against TryParseInt32 (the fully optimized version), and int.TryParse. Note that all of the conversions were valid conversions, and full validity checking was in place for all three methods (aka, make sure the value that goes in is the value coming back out). Fortunately, TryParse is only 7x slower than TryParseInt32 now, which is a step in the right direction, and it doesn't throw exceptions, nor require a cast from double in the case you used double.TryParse. I'm definitely glad they added the new TryParse methods because they give you one liner options that you would have needed a bit of code for before.
C:\Projects\CSharp\Performance\NumberUtilities>TryParseInt32
Preallocate strings
Preallocation complete
TryParseInt: 00:00:01.0114544
TryParseInt32: 00:00:00.3404896
int.TryParse: 00:00:02.5336432
// Old options without DWC.NumberUtilities or the new BCL TryParse methods
// The old try method
try { int.Parse(); } catch {}
// The double TryParse method with range checking
double.TryParse(); if (retVal < int.MinValue || retVal > int.MaxValue) {}