|
Home > Archive > BizTalk Server Orchestration > June 2004 > Web Services Publishing Wizard
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Web Services Publishing Wizard
|
|
| Chris 2004-06-20, 11:09 pm |
| I've created an orchestration with an "ancestor" XSD that points to a hierarchy of "descendant" XSD schemas (all of which are in the orchestration). I've been able to build the orchestration and deploy to the BT server. The assembly'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.BizTalk.WebServices.PublishingException] Failed to create the code for schema 'urn:name/ancestor'. The datatype 'urn:name/descendant' is missing."
Anyone have ideas what might be happening or what I might try? Thanks!
| |
| Chris 2004-06-20, 11:09 pm |
| I tried moving the schemas into a separate assembly, which I GAC'd and referenced 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?
| |
| Chris 2004-06-20, 11:09 pm |
| 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 doesn'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 someone else some pain.
BTW, is anyone still reading this group? It's like I'm writing in my diary...
| |
| Chris 2004-06-20, 11:09 pm |
| 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...
| |
| Matt Milner 2004-06-20, 11:09 pm |
| 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...
>
>
| |
| Chris 2004-06-26, 10:53 am |
| 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 schema changes so this works f
or us. I'm going to revisit later, though - I'm pretty sure this is a problem 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 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...
>
>
>
|
|
|
|
|