Well, overload resolution is determined by the parameter types, right?
You'll have a hard time convincing me that a 0 should not be of the
same type as 0.

The same program translated to C# does not give an error; or rather

               dt = new Foo(0, Bar.Bar0);

resolves to

       public Foo(Int32 f1, Bar b2)

So, a literal 0 in C# becomes an integer and a literal 0 in VB becomes
some kind of generic enumeration.  I say generic enumeration because
if I add an enum Sna that is basically the same as Bar and

       Public Sub New(ByVal s1 As Sna, ByVal s2 As Bar)

...

           dt = New Foo(CInt(0), Bar.Bar0)

I get a compiler error that

error BC30521: Overload resolution failed because no accessible 'New'
is most specific for these arguments:
   'Public Sub New(s1 As Sna, s2 As Bar)': Not most specific.
   'Public Sub New(s1 As Bar, s2 As Bar)': Not most specific.

In contrast, the same thing in C# works; or rather, since 0 defaults
to an integer, the overload to use is never in question.

It seems that the creators of VB have lumped enumerations in with
integers, just a more specific variety, most likely because the
underlying implementation has the storage characteristic of an
integer.  In OO programming, I prefer that the underlying storage or
implementation is entirely unknown on the surface.  Playing with some
code,

               Bar test;
               test = Bar.Bar0 + Sna.Sna0;

gives a compile error; whereas,

           Dim test As Bar
           test = Bar.Bar0 + Sna.Sna0

assigns the value Bar1 to test.

It seems sloppy to me that two enumerations that are entirely
different, say Apples and Oranges, can be added or compared.  For more
language differences between enum types compare

               Boolean test;
               test = (Bar.Bar0 == Sna.Sna0);

which gives a compiler error, with

           Dim test As Boolean
           test = (Bar.Bar0 = Sna.Sna0)

which assigns the value True to test.

That's about all I have to say on the subject. I concede that that's
the way it is and when some customer runs into this problem while
trying to use my type, I'll just have to tell them to assign the value
0 to a variable before using it in a constructor.

-Chris

Jon,
That's true, I simplified my statement.

Jay

Chris,

Unfortunately with VS.NET 2002 & VS.NET 2003 you will be losing some hair.

As that is how it is currently defined to work! I stated I have not tried
VS.NET 2005 (aka Whidbey, due out in 2005) to see if things are improved or
not. I really hope they will be!

Try

   Dim zero As Integer = 0

   dt = New Foo(zero, Bar.Bar0)

As that is the only way I know of to get VS.NET 2002 & VS.NET 2003 to work.
Yes MS knows there is a problem! As I told them a year ago when I came
across this quirk and remembered them when you asked your original question.

Remember that

   Dim myBar As Bar

Will have the value of literal 0 per the CTS. Also remember that the CLR
does not validate values within an Enum, if you need validation of the
values you can use Enum.IsDefined.

   If Not [Enum].IsDefined(GetType(Bar), myBar) Then
       Throw New ArgumentOutOfRangeException("myBar", myBar, "Invalid Enum
Bar value!")
   End If

Hope this helps
Jay