Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Fun with Enums

A project I'm working on is having a problem with enumerations.

The VB.NET solution consists of two Class Library projects ("Lib1" and "Lib2") and one WinForms application ("Client").  Lib2 references Lib1, and Client references both Lib2 and Lib1. 

Lib1 has a public enumeration ("SomeEnum") with two or three members.  Lib2 has a System.Windows.Forms.Form class ("Lib2Form"), which has a property ("SomeProp") of type SomeEnum.

The Client declares an instance of Lib2.Lib2Form and sets the SomeProp property of Lib2Form to SomeEnum.Member1.  While typing the code, Intellisense recognizes SomeEnum and lists all the members, but afterwards returns the following error:

"Option Strict On disallows implicit conversions from 'Lib1.SomeEnum' to 'Lib1.SomeEnum'."

However, if I move the enumeration from Lib1 to Lib2, everything is fine.  What's wrong with putting the enumeration declaration in Lib1, and why is Visual Studio trying to do a conversion to the same type?

Joe Paradise
Tuesday, June 08, 2004

From your description, nothing is wrong with your code. It's just an IntelliSense bug. Enums are kind of flaky, I often get no or a wrong IntelliSense list for C# enums.

Chris Nahr
Wednesday, June 09, 2004

I think I agree with Chris, but can you post your enum code, just to be sure?  It always troubles me when a problem like this raises 0 useful google groups results... thx.

Greg Hurlman
Wednesday, June 09, 2004

I looked through Google Groups before posting and didn't see anything either.

The problem isn't with IntelliSense; while typing code to set the property value IntelliSense lists the members of the enumeration as expected.  VS shows the build error in the Task List after you move off of the line of code by hitting the return key.

The error itself doesn't make any sense, because I'm not doing a type conversion.  Even the error text shows the same type on both sides of the conversion!

I made this test solution trying to reproduce the error under simpler circumstances, but this one compiles!


Public Enum PropertyEnum
End Enum


Public Class Form2

  Inherits System.Windows.Forms.Form

  Public Property SomeProp() As ClassLibrary1.PropertyEnum

    End Get
    Set(ByVal Value As ClassLibrary1.PropertyEnum)

    End Set
  End Property

End Class


Module Module1

  Sub Main()

    Dim c2 As New ClassLibrary2.Form2

    With c2
      .SomeProp = ClassLibrary1.PropertyEnum.PropVal1  <== error
    End With

  End Sub

End Module

So the sample solution compiles, but the production code (doing the same thing) does not.  Any ideas what could be wrong?  Thanks for your replies.

Joe Paradise
Wednesday, June 09, 2004

Not sure if this matters, but I'm using Visual Studio 2003 (.NET Framework 1.1).

Thanks again for your help.

Joe Paradise
Wednesday, June 09, 2004

The first/only thing that comes to mind is that your enum values are not assigned values of their own explicity.  Try giving each enum value an integer value, and see if that clears up the problem.

FWIW, it definitely seems to be a compiler/VS bug.

Greg Hurlman
Wednesday, June 09, 2004

I just tried assigning explicit values to every member of the Enum with no success.

Also, I tried swapping around the Enum used for Form2.SomeProp.  Any Enum defined in ClassLibrary1 will generate an error, but if you move the Enum definition over to ClassLibrary2, everything compiles.

This is one of those problems I could just fixate on and lose all productivity...

Joe Paradise
Wednesday, June 09, 2004

The ClassLibrary1 prefix must denote a declared namespace. I don't see those in your samples, maybe you just forgot to type them? If not: Assembly names are not automatically adopted as namespace names, you have to explicitly state them.

Chris Nahr
Wednesday, June 09, 2004

I left the namespaces out for simplicity.  The namespaces in both the sample code (posted above) and the production code check out.  The appropriate values are in each project's Root Namespace property.  The Class View window shows the namespace hierarchy as expected, and IntelliSense is able to list the appropriate members from each library.

I keep coming back to the build error message.  Why is Visual Studio doing an implicit conversion between the same type?  Why is this necessary?  And how can data loss be possible if the original and converted type are the same?

Joe Paradise
Wednesday, June 09, 2004

Maybe this will illuminate things.  The error goes away if I change the SomeProp definition to:

Public Property SomeProp() As Integer

Why would this matter?  The default data types for Enums are Integers, so PropertyEnum.PropVal1 is already an Integer.  It's as if because PropertyEnum is in another library/namespace, VS is trying to do a conversion.

Joe Paradise
Wednesday, June 09, 2004

Okay, I have no idea what's wrong then... sorry!

Chris Nahr
Thursday, June 10, 2004

I think I found the cause of the problem.  It has to do with the project-level references to ClassLibrary1. 

The implicit conversion error will occur when the reference to the common library are different types. 

- If ClassLibrary2 uses a compiled reference (specify the ClassLibrary1.dll file on the .NET tab) and WindowsApplication1 uses a project reference (specify ClassLibrary1 on Project tab), or vice versa, the error occurs.

- If *both* ClassLibrary2 and WindowsApplication1 use either compiled references or project references, the error disappears.

- The reference type between ClassLibrary2 and WindowsApplication1 does not appear to affect the error.

Thanks for everybody's help!

Joe Paradise
Thursday, June 10, 2004

That probably means assembly versions are not specified so you link against different assemblies every time.

Try setting versions explicitly (and it also might be what you actually want)

Thursday, June 10, 2004

That's an excellent point.  It's DEFINITELY something with the type of project references, althought I'm finding it more complicated than the scenarios in my last post.

These libraries are versioned and compiled independently in their own solutions by our automated build process.  The solution I'm working with is strictly for code development and debugging (not in source control). 

I was using project references because I was constantly encountering the "Unable to copy assembly" error for projects referenced by file.  Maybe this area will get some attention from MS in VS 2005.

Joe Paradise
Friday, June 11, 2004

*  Recent Topics

*  Fog Creek Home