I've created an orchestration with an "ancestor" XSD that points to a hierar
chy of "descendant" XSD schemas (all of which are in the orchestration). I'v
e been able to build the orchestration and deploy to the BT server. The asse
mbly's in the GAC. I've val
idated all of the schemas in the orchestration.

When I run the publishing wizard, it fails with the following error message:

"Failed to create project http://localhost/MySvc_Proxy. [Microsoft.BizTa
lk.WebServices.PublishingException] Failed to create the code for schema 'ur
n:name/ancestor'. The datatype 'urn:name/descendant' is missing."

Anyone have ideas what might be happening or what I might try? Thanks!

[ Post a follow-up to this message ]

I tried moving the schemas into a separate assembly, which I GAC'd and refer
enced from the orchestration project.

Still the same issue. Schemas validate fine and the orchestration references
 them fine. Has anyone run into this or something similar?

[ Post a follow-up to this message ]

OK, taking baby steps.

It appears that the WS publishing wizard is calling xsd.exe to generate the 
XMLSerialization classes to represent the schema. Unfortunately, xsd.exe doe
sn't support the schemaLocation attr on imports or includes, which my xsd is
 packed with.

I'll post a solution here when I figure it out. Hopefully this will save som
eone else some pain.

BTW, is anyone still reading this group? It's like I'm writing in my diary..
.

[ Post a follow-up to this message ]

If you run into this, quickest solution may be to merge your XSD into a sing
le file.

XSD.exe will work with imports if you specify the name of each imported sche
maLocation on the command line, unless you have the same targetNamespace in 
more than one schemaLocation. But then you'd need to figure out how to make 
the publishing wizard pass
the schemaLocations to XSD when it runs, so most likely it won't be worth th
e effort - isn't for me at least...

[ Post a follow-up to this message ]

Does it work if your main schema has the location attribute for the import
statements?  I have had this problem with the WSDL tool and needed to use
the location attribute to point to the included schemas.  Not sure if the
same concept applies here though.

Matt


"Chris" <Chris@discussions.microsoft.com> wrote in message
news:87ECAF47-21FA-4893-93B1-C4067A88AAB5@microsoft.com...
> If you run into this, quickest solution may be to merge your XSD into a
single file.
>
> XSD.exe will work with imports if you specify the name of each imported
schemaLocation on the command line, unless you have the same targetNamespace
in more than one schemaLocation. But then you'd need to figure out how to
make the publishing wizard pass the schemaLocations to XSD when it runs, so
most likely it won't be worth the effort - isn't for me at least...
>
>

[ Post a follow-up to this message ]

Matt,

Thanks for the response. Unfortunately, it still did not work even with the 
location attribute. I was burning way too much time so I just pulled all the
 schema files into a single XSD. We're only dealing with minor quarterly sch
ema changes so this works f
or us. I'm going to revisit later, though - I'm pretty sure this is a proble
m I'll need to solve again at some point...

-Chris

"Matt Milner" wrote:

> Does it work if your main schema has the location attribute for the import
> statements?  I have had this problem with the WSDL tool and needed to use
> the location attribute to point to the included schemas.  Not sure if the
> same concept applies here though.
>
> Matt
>
>
> "Chris" <Chris@discussions.microsoft.com> wrote in message
> news:87ECAF47-21FA-4893-93B1-C4067A88AAB5@microsoft.com... 
> single file. 
> schemaLocation on the command line, unless you have the same targetNamespa
ce
> in more than one schemaLocation. But then you'd need to figure out how to
> make the publishing wizard pass the schemaLocations to XSD when it runs, s
o
> most likely it won't be worth the effort - isn't for me at least... 
>
>
>

[ Post a follow-up to this message ]