How to determine what schema files (xsd) to include on my svcutil command line?

Question

Using svcutil, I'm trying to generate a proxy class for a web service endpoint which follows the OGC CSW 2.0.2 (07-006r1) standard for catalog services.

I've downloaded the entire OGC schema files and placed them into my "D:/temp/OGCSchemas/" Directory.

The schema i'm interested in is CSW, however CSW schema includes and imports other schemas and that's why i've downloaded the entire set.

For example you will see something like this:

<wsdl:import namespace="http://www.opengis.net/cat/csw/2.0.2/requests" location="./xml-interfaces.wsdl"/>
<xsd:schema targetNamespace="http://www.opengis.net/cat/csw/2.0.2" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" version="2.0.2">
    <xsd:include schemaLocation="../../csw/2.0.2/CSW-discovery.xsd"/>
    <xsd:include schemaLocation="../../csw/2.0.2/CSW-publication.xsd"/>
</xsd:schema>

My command line so far looks like:

svcutil D:\temp\OGCSchemas\csw\2.0.2\examples\wsdl\2.0.2\*.wsdl D:\temp\OGCSchemas\csw\2.0.2\*.xsd D:\temp\OGCSchemas\filter\1.1.0\*.xsd D:\temp\OGCSchemas\ows\1.0.0\*.xsd /out:D:\temp\ogc.csw.proxy.cs

But I'm getting many errors that look like this:

Error: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[@targetNamespace='http://www.opengis.net/cat/csw/2.0.2/soap']/wsdl:binding[@name='csw-SO
AP']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://www.opengis.net/cat/csw/2.0.2/wsdl']/wsdl:service[@name='CSW']/
wsdl:port[@name='csw-SOAP-Port']

I believe this error is telling me to include more xsds in my command line.

So my question is: How do i determine which xsds to include in my command line?

I thought i'd included a *.xsd for every directory that it was including from, but obviously not.

EDIT #1 What are the rules when including xsd files? Must all files that are imported or included be added? With such a big schema, I'm thinking i'm going to need to build a tool to find them all.

Ineducation

where's the WSDL you're trying to import? – Constructive

@John: on my local machine: D:\temp\OGCSchemas\csw\2.0.2\examples\wsdl\2.0.2\http-binding.wsdl online they are at: schemas.opengis.net/csw/2.0.2/examples/wsdl/2.0.2/… – Ineducation

Answer 1

Not sure if this was the right way to go about it, but i created a program that would go through the schema and create my command line for me by following all "xs:import", "wsdl:import", "xsd:include", "xsd:import", and "include" xml elements recursively.

I ended up with the following command line which finally got generating code. But the code is way to small. Something is still wrong. But at least i was able to determine what files to include in the command line.

command line:

svcutil D:\temp\OGCSchemas\csw\2.0.2\http-binding.wsdl D:\temp\OGCSchemas\csw\2.0.2\xml-interfaces.wsdl D:\temp\OGCSchemas\csw\2.0.2\responses.wsdl D:\temp\OGCSchemas\csw\2.0.2\CSW-discovery.xsd D:\temp\OGCSchemas\csw\2.0.2\CSW-publication.xsd D:\temp\OGCSchemas\ows\1.0.0\owsExceptionReport.xsd D:\temp\OGCSchemas\csw\2.0.2\record.xsd D:\temp\OGCSchemas\ows\1.0.0\owsAll.xsd D:\temp\OGCSchemas\filter\1.1.0\filter.xsd D:\temp\OGCSchemas\csw\2.0.2\rec-dcterms.xsd D:\temp\OGCSchemas\csw\2.0.2\rec-dcmes.xsd D:\temp\OGCSchemas\ows\1.0.0\owsGetCapabilities.xsd D:\temp\OGCSchemas\filter\1.1.0\expr.xsd D:\temp\OGCSchemas\filter\1.1.0\sort.xsd D:\temp\OGCSchemas\filter\1.1.0\filterCapabilities.xsd D:\temp\OGCSchemas\gml\3.1.1\base\geometryAggregates.xsd D:\temp\OGCSchemas\ows\1.0.0\owsServiceIdentification.xsd D:\temp\OGCSchemas\ows\1.0.0\owsServiceProvider.xsd D:\temp\OGCSchemas\ows\1.0.0\owsOperationsMetadata.xsd D:\temp\OGCSchemas\gml\3.1.1\base\geometryPrimitives.xsd D:\temp\OGCSchemas\ows\1.0.0\owsDataIdentification.xsd D:\temp\OGCSchemas\ows\1.0.0\ows19115subset.xsd D:\temp\OGCSchemas\ows\1.0.0\owsCommon.xsd D:\temp\OGCSchemas\gml\3.1.1\base\geometryBasic2d.xsd D:\temp\OGCSchemas\gml\3.1.1\base\geometryBasic0d1d.xsd D:\temp\OGCSchemas\gml\3.1.1\base\measures.xsd D:\temp\OGCSchemas\gml\3.1.1\base\units.xsd D:\temp\OGCSchemas\gml\3.1.1\base\dictionary.xsd D:\temp\OGCSchemas\gml\3.1.1\base\gmlBase.xsd D:\temp\OGCSchemas\gml\3.1.1\base\basicTypes.xsd D:\temp\OGCSchemas\xlink\1.0.0\xlinks.xsd /out:D:\temp\ogc.csw.proxy.cs

But the code that it generates is way to small:

[assembly: System.Runtime.Serialization.ContractNamespaceAttribute("http://www.opengis.net/ows", ClrNamespace="www.opengis.net.ows")]
namespace www.opengis.net.ows
{
    [System.Diagnostics.DebuggerStepThroughAttribute()]
    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
    [System.Xml.Serialization.XmlSchemaProviderAttribute("ExportSchema")]
    [System.Xml.Serialization.XmlRootAttribute(IsNullable=false)]
    public partial class ExceptionReport : object, System.Xml.Serialization.IXmlSerializable
    {
        private System.Xml.XmlNode[] nodesField;
        private static System.Xml.XmlQualifiedName typeName = new System.Xml.XmlQualifiedName("ExceptionReport", "http://www.opengis.net/ows");
        public System.Xml.XmlNode[] Nodes
        {
            get
            {
                return this.nodesField;
            }
            set
            {
                this.nodesField = value;
            }
        }
        public void ReadXml(System.Xml.XmlReader reader)
        {
            this.nodesField = System.Runtime.Serialization.XmlSerializableServices.ReadNodes(reader);
        }

        public void WriteXml(System.Xml.XmlWriter writer)
        {
            System.Runtime.Serialization.XmlSerializableServices.WriteNodes(writer, this.Nodes);
        }

        public System.Xml.Schema.XmlSchema GetSchema()
        {
            return null;
        }
        public static System.Xml.XmlQualifiedName ExportSchema(System.Xml.Schema.XmlSchemaSet schemas)
        {
            System.Runtime.Serialization.XmlSerializableServices.AddDefaultSchema(schemas, typeName);
            return typeName;
        }
    }
}

Ineducation

Thats one way! If it's small you might be starting with the wrong WSDL file. – Barca

Answer 2

I dealt with this the other day. The easiest way is to set them up in IIS and modify your hosts file to point those addresses to your localhost. Then use XSD on the main wsdl file and all will be good.

I'm sure there is a better way but after a few hours that is what I ended up doing.

you can try to modify the namespaces, but that didn't work for me plus you';d have to modify them for all files and thats such a pain.

Barca

@Dustin: Don't touch the namespaces. They are not related to the URL at which the schema is located. – Constructive

@John, XSD will try to pull them from there. Again, this is how I got my setup to work by mimicking the namespace urls. – Barca

@Dustin: no, never. Namespaces are URIs not URLs. They do not denote a location on the Internet. There may be an xsi:schemaLocation attribute which specifies for each namespace, where on the Internet the schema is located, but that is optional. – Constructive

yes, i know that. My point is, if he sets up IIS to mimick where the namespaces are pointing, XSD will find them. Again, this is how I solved the same issue. Had a vendor send me a bunch of WSDL files. XSD couldnt resolve them locally. What the hell? Just try it. Not getting any other answers. – Barca

@Dustin: So you're saying make "opengis.net/cat" resolve to my local files where the equivalent xsd files are? – Ineducation

@Dustin: sorry, but you're confusing namespaces with URLs. Even a namespace that looks like a URL is not a URL, and does not denote a location on the Internet. – Constructive

@Ineducation create a new IIS site, setup the folders in a way that mimick what the namespaces are referencing in the main WSDL then copy the wsdl files to that folder so they are accessable via the browser. Then run XSD on the main wsdl and it should work. you will need to add a record to the hosts file to point the "domain" of the namespace URI to your localhost. For example my wsdl had vendordomain/schemas so I added vendordomain to point to 127.0.0.1. @John is right but he fails to see how this works. – Barca

@Dustin: I appreciate the work around, however, i'm still looking to know what the official Microsoft process, rule, or methodology is in determining what xsd files to include in your command line is. If i don't get a definitive answer this week, i'll try your suggestion. Work around is better than nothing at all. – Ineducation

@Ineducation I understand. I wanted XSD to just see them since they were in the same folder but it wouldnt and visual studio wasn't any help. You might try svcutil instead of XSD. – Barca