 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / March 2007C# enum and VB.NET enum conflict?
I found this problem when I reference gotdotnet user sample Win32Security assembly in some of my VB.NET projects. The Win32Security projects are written in C#. For example, in Win32Security project, AccessType is a enum that is defined as: [Flags] public enum AccessType : uint And in my VB.NET code, the following code cannot compile: AddAce(New AceAccessAllowed(sidEveryone, AccessType.GENERIC_ALL, AceFlags.CONTAINER_INHERIT_ACE Or AceFlags.OBJECT_INHERIT_ACE)) The error is: Value of type 'Integer' cannot be converted to 'Microsoft.Win32.Security.AccessType'. More interestingly, in the above same line, AceFlags does not cause an error. AceFlags is defined as: [Flags] public enum AceFlags : byte So an Enum type that inherits from uint will cause an error but an Enum type that inherits from byte won't. What a strange thing. Okay, I just found out that this problem is solved in VS.NET 2005 beta 1. So this is a bug in VS.NET 2002 and 2003. Period. > I found this problem when I reference gotdotnet user sample > Win32Security assembly in some of my VB.NET projects. The Win32Security [quoted text clipped - 23 lines] > So an Enum type that inherits from uint will cause an error but an Enum > type that inherits from byte won't. What a strange thing. Is it a bug or simply that VB.Net 2002/3 don't support unsigned integers? I'm curious because I thought that unsigned numeric types simply didn't have an equivalent in VB.Net at this point and that they were going to add three new unsigned types in 2005? That point is a bit different from being a bug. I seem to remember that unsigned numeric values are not CLI compliant, so there may be quite a few .Net languages that simply don't support them or do some magic work to get them to the best type they can. My guess would be that because VB.Net doesn't yet recognize uint it does an under the covers conversion to int which then breaks the enum definition. I just thought it might be worth mentioning this to the group for opinions (please tell me if this is wrong, I won't be offended). Have A Better One! John M Deal, MCP Necessity Software > Okay, I just found out that this problem is solved in VS.NET 2005 beta > 1. So this is a bug in VS.NET 2002 and 2003. [quoted text clipped - 28 lines] >> So an Enum type that inherits from uint will cause an error but an >> Enum type that inherits from byte won't. What a strange thing. I think it's a bug of VB.NET. Here is the proof. I imported exactly the same assembly (win32security.dll) into one of my VS.NET 2005 beta 1 projects. And the following code can compile: Microsoft.Win32.Security.SecurityDescriptor.GetFileSecurity("c:\", Microsoft.Win32.Security.SECURITY_INFORMATION.DACL_SECURITY_INFORMATION) And I see this in Object Browser: Public Enum SECURITY_INFORMATION As UInteger Member of: Microsoft.Win32.Security So, it is a bug of VB.NET reference function. > Is it a bug or simply that VB.Net 2002/3 don't support unsigned > integers? I'm curious because I thought that unsigned numeric types [quoted text clipped - 48 lines] >>> So an Enum type that inherits from uint will cause an error but an >>> Enum type that inherits from byte won't. What a strange thing. Ahh but in VS2005, VB.NET supports unsigned types so its not a bug. Sounds like a bug in win32Security.dll - its not CLS Compliant Regards Richard Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk I think it's a bug of VB.NET. Here is the proof. I imported exactly the same assembly (win32security.dll) into one of my VS.NET 2005 beta 1 projects. And the following code can compile: Microsoft.Win32.Security.SecurityDescriptor.GetFileSecurity("c:\", Microsoft.Win32.Security.SECURITY_INFORMATION.DACL_SECURITY_INFORMATION) And I see this in Object Browser: Public Enum SECURITY_INFORMATION As UInteger Member of: Microsoft.Win32.Security So, it is a bug of VB.NET reference function. Again I don't see this as a bug because the unsigned numeric values have only just been added to VS.Net 2005, they didn't exist in 2002 or 2003. It isn't like VB.Net 2002/2003 were supposed to support unsigned integers and through some programming flaw in the language they don't (that would be a bug) instead what you have is a language that never was supposed to support unsigned numeric values and is well documented as being that way. The reason it compiles in VB.Net 2005 is not because they fixed a bug, but rather because they added three new data types that support unsigned numerics to the language. Don't get me wrong, I program in C# not VB.Net so this isn't a crusade for my language of choice, I just have an issue with calling something a bug just because it isn't supported... by design. It also isn't a bug to comply to the CLI specification without going beyond it, it may be a feature that would have been nice for them to implement but it isn't a bug. It's king of like saying that VB.Net 2003 has a bug because it doesn't support the rename refactoring that you can do in VB.Net 2005. Have A Better One! John M Deal, MCP Necessity Software > I think it's a bug of VB.NET. > [quoted text clipped - 66 lines] >>>> So an Enum type that inherits from uint will cause an error but an >>>> Enum type that inherits from byte won't. What a strange thing. I don't think it's not a bug. Since the CLR provides CTS, which has UInt32/UInt64, I couldn't think of any reason that VB.NET cannot map C# uint to System.UInt32. :-( > Again I don't see this as a bug because the unsigned numeric values have > only just been added to VS.Net 2005, they didn't exist in 2002 or 2003. [quoted text clipped - 89 lines] >>>>> So an Enum type that inherits from uint will cause an error but an >>>>> Enum type that inherits from byte won't. What a strange thing. Sorry I disagree. Current version of VB.Net didn't support unsigned types. Documented. Definitely not a bug of VB.NET. Limitation maybe, but since its documented it cannot be called a bug. The project you are trying to use supports unsigned types. No big deal there, thats a design decision, not a bug. But guess what, languages that don't support unsigned types won't be able to use it. Again not a bug, but a limitation when using multiple languages, each with their own set of handled types. > I don't think it's not a bug. > [quoted text clipped - 32 lines] > >> > >> Microsoft.Win32.Security.SecurityDescriptor.GetFileSecurity("c:\", Microsoft.Win32.Security.SECURITY_INFORMATION.DACL_SECURITY_INFORMATION) > >> And I see this in Object Browser: > >> [quoted text clipped - 56 lines] > >>>>> So an Enum type that inherits from uint will cause an error but an > >>>>> Enum type that inherits from byte won't. What a strange thing. > Since the CLR provides CTS, which has UInt32/UInt64, I couldn't think of > any reason that VB.NET cannot map C# uint to System.UInt32. :-( This is why there is a CLS - Common Language Specification - which specifies a subset of the CTS which all .NET languages should support. Components that should be usable from every .NET language must adhere to the CLS. Components that are not CLS-compliant might not be fully usable from all .NET languages. The type System.UInt32 is not a CLS type. Fabian >> Since the CLR provides CTS, which has UInt32/UInt64, I couldn't think >> of any reason that VB.NET cannot map C# uint to System.UInt32. :-( [quoted text clipped - 6 lines] > > Fabian Understood. Period. But not really period. Just want to say that those VB guys at m$ only care about money, they never take the language seriously. It took them more than 10 years to add the 'continue' language facility and, this unsigned integral type thing. :-( Do you mean using "continue" in a loop to move to the next iteration? If I see that in code I normally assume the developer needs to revisit the design. Regards Richard Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk But not really period. Just want to say that those VB guys at m$ only care about money, they never take the language seriously. It took them more than 10 years to add the 'continue' language facility and, this unsigned integral type thing. :-( > Do you mean using "continue" in a loop to move to the next iteration? > > If I see that in code I normally assume the developer needs to revisit the design. Okay, I think I can go back to my old code and replace the switch cases to if-else-if-else's. > But not really period. Just want to say that those VB guys at m$ only > care about money, they never take the language seriously. It took them > more than 10 years to add the 'continue' language facility and, this > unsigned integral type thing. :-( Well, I don't know anyone from the VB team, so I can't say what they care about, but IMO it's the right of every language designer to say that they don't need or want unsigned types. Unsigned types aren't usually mandatory for anything, in fact they complicate things a little when signed and unsigned types are combined. Fabian >> Since the CLR provides CTS, which has UInt32/UInt64, I couldn't think >> of any reason that VB.NET cannot map C# uint to System.UInt32. :-( [quoted text clipped - 6 lines] > > Fabian And, I believe that the CLS is specifically tailored to suit VB.NET. I can't think of any other language that does not have unsigned integral types til today. enum is value type. I wanna know how enum is stored in memory? The constants defined within enum block share a single storge space(2 byte or 4 byte depending on the type defined) not like struct block. So, is there any restriction on how many constants I can define within a enum block? Plz Hlp me out. I'll be thankful to From http://search.yahoo.com/search;_ylt=A0geu_a5w_5FmHYAOV6l87UF?ei=UTF-8&fr=read&fr 2=sfp&p=enum+in+vb.net&fspl= > enum is value type. I wanna know how enum is stored in memory? The > constants defined within enum block share a single storge space(2 > byte or 4 byte depending on the type defined) not like struct block. I'm not clear exactly what you're saying, but I suspect it's not true. Could you clarify exactly what you mean?  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too > enum is value type. I wanna know how enum is stored in memory? The > constants defined within enum block share a single storge space(2 byte or > 4 byte depending on the type defined) not like struct block. So, is there > any restriction on how many constants I can define within a enum block? > Plz Hlp me out. I'll be thankful to u Each constant in the enum has an integer value. That value is stored in memory. You can control the size of the integer using, for example: enum MyEnum : ushort { Zero, One, Two } Any restriction on the number of constants would come from MSIL metadata limitations, because it's possible to have several constant with the same numeric value. > From > http://search.yahoo.com/search;_ylt=A0geu_a5w_5FmHYAOV6l87UF?ei=UTF-8&fr=read&fr 2=sfp&p=enum+in+vb.net&fspl=0 > > Posted via DevelopmentNow.com Groups > http://www.developmentnow.com
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.