xsd.exe fails to create common data types out of nested schemas
Hi,
with the contract first approach we have somexsdschemas as the core interface definitions. We outsourced common data types (enumerations and some length limited string types) in a sharedcommon.xsdfile which in turn is<import>ed into the top levelxsd schemas.
We tried to generate.cscode files withxsd.exein this scenario. But all the generated code files repeatingly contain the common data type definitions. This leads into several compiler errors. Using different namespace delcarations for each generated class does not solve the problem: The shared character of our common data types is completely lost after code generation withxsd.exe!
It seems to be a popular problem, because shared data types is a commonly used practice. Does anyone solved this problem already? How can we deal with this? Any suggestions?
[1225 byte] By [
frk] at [2007-12-26]
Hi, we had a similiar issue. The main reason is that you can't tell the xsd.exe tool to only generate classes for the first schema and not the supporting schemas, so a little manual cleanup is in order. Because of how .net compiles everything, I found the following workflow to be helpful:
Consider 3 files, common.xsd, obj1.xsd, and obj2.xsd. obj1 and obj2 both refer to the common.xsd to resolve certain data types.
Create all of the .cs files using the xsd.exe tool so that you end up with common.cs, obj1.cs, and obj2.cs.
Now, go into obj1.cs and DELETE all declarations for the types, enumerations, etc that are duplicated from the common.cs file. Do the same for the obj2.cs file.
Finally, add all three files to your project. The compiler will accurately locate the references.
We went one step further and added a namespace Xyz { } declaration within each of the .cs files so that all of the objects where within the same namespace.
Chris Lively.
Yes, this is indeed a workaround, thanks.
But I'm afraid of the manual effort. In this manner, creating the C# classes cannot be integrated in the normal build process. Has anyone any further suggestions?
frk at 2007-9-4 >
Try this - if you take the example above - obj1.xsd and obj2.xsd both imports the namespace from common.xsd - I am guessing the both use "namespace" and "SchemaLocation" attributes to do this.
A work around could be to "only" import the namespace (and not the document)
Use <import namespace="targetnamespace-from-common.xsd"/> and NOT <import namespace="targetnamespace-from-common.xsd" schemaLocation="common.xsd"/>
After that you just feed the documents to Xsd.exe as parameters - like this:
>xsd.exe /c obj1.xsd obj2.xsd common.xsd
Thanks for your proposal. Sadly, it doesn't work. The outcome is the same, if the schemaLocation attribute is given in the import tag or not.
I guess, you tried this by yourown and it seems to work in your environment. Which version of the xsd.exe tool were you using?
frk at 2007-9-4 >
Using version 2.0.50727.42 and I have seperate namespaces for each xsd document given as parameter to xsd.exe (I think that is important othervise xsd.exe will state somthing like "have already loaded this namespace" upon reading the same targetNamespace twice - xsd.exe associates a namespace with a document - so no two documents can have the same namespace).
You should be able to get around it if you can live with having all your generated code in one file. I am guessing that you have allready been there - so thats probably not an option.
Oh, generating only one code file is in fact not an option. We have several xsd files, and generating a single code file is not possible due to the resulting length of the command line and the strangeness of the generated file name. Thanks for your aid, anyway.
By the way: It's not a concern of the schemaLocation attribute. This attribute is not evaluated by xsd.exe, see the documentation.
frk at 2007-9-4 >
Ohh...man...frk...this is the exact problem i've been having for the last few days...no matter what i've tried the thing just won't work! I've googled the earth for hours finding a solution and then finally i came up with the idea of all of them being in the same file. And what i get!?!?
" - The specified path, file name, or both are too long. The fully qualified fil
e name must be less than 260 characters, and the directory name must be less tha
n 248 characters."
F....f...f.f.f..f.f.f!!!! And there is no option to give the XSD.EXE tool the name of the file to generate...wtf!!! I can't shorten the file names cause they are descriptive and have a version tag. At this point i wished to be on a island far away from everything. But no...i realized i can't use the XSD.EXE and that i have several options:
1. change my schema design dramatically...nah...
2. use some other generating tool..nah....
3. make my own objects for the schemas...probably...
But then...what is the point of the XSD.EXE tool if you can't have a common.xsd for types. Any bigger project will require it cause i think it's a good design technique. Well, anyways i hope that somebody will enlighten me cause i really feel like using this xsd.exe tool.
Peace!
Yes, indeed! It did help! Thank you. A big thing for me is to know that others are having problems too. I guess i thought there was a tool that does everything i want. I liked that comment in the link saying: "Yes, you will have to like the generated code!". For others stumbling around with this problem: visit the link above and below. There is no easy way out. You will have to spend a bit of time with adjusting the generated objects. Although i wish someone could write a tutorial on doing a xsd project with a commonTypes.xsd file. I thought it would be rather of a standard design techique by now.
almost forgot:
http://petesbloggerama.blogspot.com/2005/07/contract-first-and-xsdobjectgen.html
