Bearing in mind that Type objects look the same regardless of what language you are using, why would you expect it to give you a VB-specific name? How's it supposed to know what language you're calling from.
In fact it doesn't use C# syntax either - it can come up with type names that won't compile in either C# or VB.NET. For example, if you create a one-dimensional array whose lower bound is anything other than zero, you'll end up with something like System.Byte[*], which won't compile in either C# or VB.NET. The strings you are seeing here are, unsurprisingly, the CLR's names for the types. It's true that these look slightly more like C# than they do VB.NET. This probably tells you something about the background of the average developer on the CLR team... But it's not accurate to say that these strings are in C# syntax, and it's not reasonable to expect the CLR to somehow detect what language you were writing in and modify these type strings to match. (It's all just IL as far as the CLR is concerned.) As for the problem you're trying to solve, why don't you use the CodeDOM to generate your code? That abstracts away details like this, and allows the CodeDOM implementation you're using to decide on the right way to describe a particular type in your language of choice. Any realistic solution to this problem that Microsoft could have provided is going to have to look something like this anyway - the set of languages is unbounded in .NET: anyone can write their own programming language! So they can't simply define an enum of all the languages and provide a property of the Type object that uses that to let you choose what flavour you'd like your type expressions in. You might be using a language that the team that wrote the Type object haven't even heard of. To solve this problem in a general way, there will always need to be some body of code supplied by the language vendor (or at least specific to that language). Admittedly the CodeDOM is a rather heavyweight solution to the specific problem you're focusing on, but it actually solves a whole raft of code-gen problems. (And since the problem you describe is one you're most likely to come across in a code gen scenario, it's not unreasonable that the facility for doing this is a part of the CodeDOM.) -- Ian Griffiths DevelopMentor > -----Original Message----- > From: Frans Bouma [mailto:[EMAIL PROTECTED] > > Ok, I'm now struggling with some VB.NET related stuff. If I do this: > Dim arr() As System.Byte = New System.Byte(10) {} > Console.WriteLine("type = " & arr.GetType().ToString()) > > I'd expect to see: > type = System.Byte() > > however I see: > type = System.Byte[] > > I understand that the type's ToString() has to report something, but > isn't there a setting I can set so it will return VB.NET syntaxis? (And > I don't have to alter my code emitter? :D) =================================== This list is hosted by DevelopMentorŪ http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com
