none
?xsd=xsd2 in xsd:import schemaLocation in WSDL - whats going on??? RRS feed

  • Question

  • Hi,

    Can anybody tell me what exactly is going on behind the facade, in the WSDL that the WCF publishing wizard creates?

    I'm specifically thinking about the

     <xsd:schema targetNamespace="http://myservices/replacedcustomernamespacewithtext/Imports">
    <xsd:import schemaLocation="https://servername(replaced)/Test/replacedname/replacednameofservice.svc?xsd=xsd2"
    namespace="http://replacednamespaceofschema"/>
    


    namespaces and URI's have been altered. Even I don't create such ugly names :D

    Whats happening behind the facade with the ?xsd=xsd2 ???   I looked into the APPDATA and TEMP folders to see if there was a reference to let the WSDL resolve the XSD2 to the actual schema?  Couldn't find any.  Or is it doing this using the TNS of the schema?

    I was trying to get a metadata point to work behind an ISA server, using a WSDL I had customized, and it stranded on not being able to resolve the schema's.  I would love to understand what exactly happens at "resolving" time when SVCUTIL comes by.

    It all works fine if I copy WSDL and schemas locally, point the imports to actual local schema files and let SVCUTIL create proxy code and boilerplate config files.

    It's not a problem per se ... more a case of ... "this bugs me because I don't understand whats being created behind the scene and I know it'll bite me at one point"  :D    I bet we've all been down that road ...

    regards
    Lars
    Wednesday, October 21, 2009 11:10 PM

Answers

  • Hi Lars,

    My opinion is you can use tools like fiddler to capture netmon trace to see what SVCUTIL tries to access when resolving the XSDs. This may show you the details about some external resources SVCUTIL fails to retrieve.

    Thanks.
    WenJun Zhang - MSFT Sincerely Microsoft Online Community Support "Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. "
    Wednesday, October 28, 2009 10:00 AM
    Moderator

All replies

  • So you are trying to enable MEX for your published service? I think there is a checkbox for this in the WCF Publishing Wizard.

    Also, what you you mean by "a WSDL I had customized"? 

    The WSDL is basically generated for the service so you can get some weird things popping up. The xsd=xsd2 thing looks like a schema resolution thing. I think there is probably a .NET assembly you could reflect on to find what is using the xsd=xsd2 thing, let me look around a while for this. It may be as simple as looking in the .svc file for the type behind the service to find the assembly to reflect on.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Thursday, October 22, 2009 3:47 PM
    Moderator
  • Hi Again Ben,

    Thanks for helping me out on the UDDI SQL server issue! Here you are again :)

    What I mean is that I used the wizard to create a WCF service frontend to my orchestration, and I host it in the IIS. I also asked the wizard to create a MEX at the same time, and all is well. It's working locally or within the LAN just fine.

    Now I want to expose it over the internet, using an ISA server and for starters - transport only security. That works too with the client and the config I created locally, after manually editing the config to support httpsGetEnabled="true

    Now I want to go one step further and let my external client harvest the proxy and config, and they are accessing the services on my external address that I have created.  (I wont list the actual address here but its something like  services.mywebsite.com/test for testservices and without the /test for production services.

    For this purpose I save the automatically created WSDL, and replace the hostname of the server, where it lists the address. It does so in the XSD:Import location attributes and the Address segment at the bottom of the WSDL. 
    I then use the externalMetadataLocation="" to point at this new WSDL file on an address accessible through my external link  like this:  https://services.mydomain.com/test/myservice/myservice.wsdl
    I've also edited this line in the webconfig to reflext the metadata to be exposed over https. Is that not correct?
    <endpoint name="HttpsMexEndpoint" address="mex" binding="mexHttpsBinding" bindingConfiguration="" contract="IMetadataExchange" />

    But SVCUTIL seems to choke when it is trying to resolve the address of the XSD's, even though they are available at that URL.

    I can solve it by handing over WSDL and XSD's to the client, and harvest proxy and config just fine, but out of spite i would love to get the original thing to work. I bet I can learn a lot about what is really going on in behind the scene by that and I havent found a good post or documentation on that. Yet.
    And I would still love to expose my endpoint for this particular service in this way.

    I am especially curious as to what is happening with original XSD:import statement when you harvest the proxy/config??

    Do you understand what I mean?

    regards
    Lars
    Thursday, October 22, 2009 7:51 PM
  • Hi Lars,

    My opinion is you can use tools like fiddler to capture netmon trace to see what SVCUTIL tries to access when resolving the XSDs. This may show you the details about some external resources SVCUTIL fails to retrieve.

    Thanks.
    WenJun Zhang - MSFT Sincerely Microsoft Online Community Support "Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. "
    Wednesday, October 28, 2009 10:00 AM
    Moderator
  • Hi Wen-Jun,

    Thanks for answering. Looking at it with Fiddler sounds like a good idea.

    Lets just close this here - it was purely rooted in my curiosity for what is going on in the line below, and not an actual problem.
    xsd
    :
    import
     schemaLocation
    =
    "
    https://servername(replaced)/Test/replacedname/replacednameofservice.svc?xsd=xsd2
    "
    

    regards
    Lars
    Wednesday, October 28, 2009 7:59 PM
  • Hi LarsWa,

    You checked the SchemaIdex file in your service's artifacts folder in wwwroot?

    There you will see the names of schemas and their assembly details.

    Schema locations in WSDL file is pointing the details of this file. 

     


    Anoop Gupta: BizTalk Developer
    Monday, May 2, 2011 5:21 PM