I ran into this problem at work today, which reminded me why case insensitive languages (like Visual Basic) suck. Or if you prefer, I found a bug in a Microsoft tool. I was using xsd.exe to generate a type safe class for an XML schema that I received from a company we do business with. Instead of reproducing all the schema and code here, I'll boil it down to the simplest code which still reproduces the problem. Let's say you have an XML schema that looks like this:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="Node">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="VALUE" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
And here is an XML fragment which will obey this schema:
<?xml version="1.0" encoding="utf-8" ?>
<Root>
<Node VALUE="Hello">World</Node>
</Root>
Pretty simple so far, right? If you save that schema off as XmlDoc.xsd, and then run xsd against it using the following command line options:
xsd XmlDoc.xsd /c /f /l:VB
You will get the following class definition as output:
'------------------------------------------------------------------------------
' <auto-generated>
' This code was generated by a tool.
' Runtime Version:2.0.50727.42
'
' Changes to this file may cause incorrect behavior and will be lost if
' the code is regenerated.
' </auto-generated>
'------------------------------------------------------------------------------
Option Strict Off
Option Explicit On
Imports System.Xml.Serialization
'
'This source code was auto-generated by xsd, Version=2.0.50727.42.
'
'''<remarks/>
<System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42"), _
System.SerializableAttribute(), _
System.Diagnostics.DebuggerStepThroughAttribute(), _
System.ComponentModel.DesignerCategoryAttribute("code"), _
System.Xml.Serialization.XmlTypeAttribute(AnonymousType:=true), _
System.Xml.Serialization.XmlRootAttribute([Namespace]:="", IsNullable:=false)> _
Partial Public Class Root
'''<remarks/>
Public Node As RootNode
End Class
'''<remarks/>
<System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42"), _
System.SerializableAttribute(), _
System.Diagnostics.DebuggerStepThroughAttribute(), _
System.ComponentModel.DesignerCategoryAttribute("code"), _
System.Xml.Serialization.XmlTypeAttribute(AnonymousType:=true)> _
Partial Public Class RootNode
'''<remarks/>
<System.Xml.Serialization.XmlAttributeAttribute()> _
Public VALUE As String
'''<remarks/>
<System.Xml.Serialization.XmlTextAttribute()> _
Public Value As String
End Class
What you'll notice is that that RootNode class has two fields named Value. One of them is upper case (as it was in the schema declaration), and the other is Pascal case. This second one is marked with the XmlTextAttribute, meaning that it is the property which represents the Element Text value (in my sample XML document it would be equal to "World" while VALUE would equal "Hello").
If we were doing this in C#, all would be fine and dandy since it's case sensitve. However, with Visual Basic, this generates a compiler error. In the case of my 1300 line schema file at work, I had to modify 42 different fields that met this pattern. And because I had to hand modify an auto-generated file, there is no way that I can automate this generation as part of a build process... which sucks if the schema ever changes.
Wouldn't it be nice if xsd.exe were actually smart enough to verify that there was no name collision with the Value field before it used it, and chose an alternate name... or perhaps had a command line argument were you could provide a name to override the default?