Is it just me, or does it seem like there was a change in the way wsdl.exe and the VS2005 Add Reference Wizard generated code regarding XML namespaces for generated classes, compared to previous versions (beta 2 more explicitly)
In the particular case I've run into it seems that for message classes, the [XmlTypeAttribute] that is added to the class declaration when they are generated no longer contains the XML namespace, and instead the code relies completely on the namespace being set at the WebMethod parameter in an [XmlElement] attribute.
While this certainly works, it does tend to break code that was using the generated classes. For example, I have some code here that depended on that namespace being set because it serialized objects from those classes under different contexts, which now breaks unless I modify either my code or the generated wizard code.
Anyone else noticed this

XmlTypeAttribute & Namespace in WebService proxy generation
Pastor Charles
I've asked the Serialization team to look into this and they should get back to you shortly.
Daniel Roth
ian88
BjornL
It is hard to answer without an actual service description (wsdl file), but I am going to guess that you are running into the behavior change dealing with anonymous types.
Types in question that lose the Namespace property are defined in the wsdl as anonymous: they are not declared at the top level of the schema and do not have names. The [XmlType] attribute should have AnonymousType=true property set.
Types like that only intended to be serialized in the context of a single element in which scope they were declared.
We had to add this AnonymousType=true feature to solve several problems with name collision, the unfortunate side effect you see was not avoidable.
Thanks,
Elena< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
shaen
I think I won't notice this if you don't mention it ,
admire it!
anoo
Thanks for the answer, that makes some sense, and yes, the types are actually marked as anonymous (though I could change my existing webservice code to fix it).
Could you explain in more detail what exactly the name clash problem you fix by this is I'm guessing it is done to prevent cases where you have in a single WSDL definition both a named type and an element with the same name that defines an anonymous types I do admit that I'm not entirely sure how just removing the namespace on the type definition might actually avoid the name clash (after all, you might well end up with the opposite case)...
I don't mind it all that much now that I *think* know how to get around it, though I have to admit it was quite unexpected; it definitely deserves being well documented at the very least, as it can brake quite a bit of code, unfortunately.
worb
Great, excellent.
Meanwhile, I found out that I can get around this issue in my case without actually modifying the code.
Since the classes generated by WSDL.EXE/Add Web Reference Wizard for messages are partial classes, I can just create a new code file and extend the partial class of my main messaging types with empty definitions that add an [XmlRoot] attribute as appropriate.
Partial classes rule :)
khkassem
The name clash issue that Elena is referring to has to do with the way we used to make up a name for anonymous types prior to ASP.NET Web Services 2.0. We used to construct a name for anonymous types using the enclosing elements. If there happened to be a named type with the same name we would correct the generated types to have different names so that the code would compile, but the schema type names remained the same. So, if you tried to roundtrip these types back into schema you would get a name clash. We added the anonymousType attribute to avoid this problem.
I agree that this issue needs to be well documented. I will follow up to make sure that this has been done.
Thanks for this feedback!
Daniel Roth