But as another poster pointed out, many VB backward-compatibility functions
have subtle (and sometimes evil) behaviors that are designed for VB6
compatibility, and if the code expressly or unconsciously relies on these
behaviors, then using straightforward CLR code may get the job done but
without the VB6 side effects and therefore without the exact same execution
path.

I don't know how much of a newbie the OP was but really the simplest answer
is:

string a = "123";
int c = Convert.ToInt32(a);

... or the equivalent ToDouble() or whatever.  But you have to ask yourself
what happens with boundary conditions such as an empty, null or non-integer
string with the original Val() function, and then if the behavior is
different you have to decide whether it matters, or whether you want to use
more standard or robust methods of dealing with those boundary conditions.

One of VB.NET's dirty secrets is that in an effort to ease the VB6 to VB.NET
transition, developers have been encouraged to use Val() and CInt() and
CType() and so forth, rather than write standard .NET API calls.  And it
creates issues such as what we're now discussing when you want to port code,
and sometimes creates issues in mixed-language projects.  Since I never did
much VB6 and learned C# as my first and primary .NET language, when I get
involved in a VB.NET project I tend to write VB.NET versions of how
something would be done in C#.  This produces somewhat different code than
most VB coders tend to write.  Not wildly so, but more CLR oriented than VB6
oriented.  My VB.NET code could get by without VisualBasic.dll.

By contrast someone who started with, say, QuickBasic and has stayed with
the language ever since understandably tends to want to write code the way
they always have, out of affection and nostalgia.  And that's arguably fine
if you really want to stay exclusively in a parochial VB-centric
environment.  But I think it cuts your flexibility down.

--Bob