.Net wsdl:import problem when parsing a wsdl made with websphere / java


  • Dear developers,

    using .Net as a client for a webservice, which seems to be build with IBM Webshere / Java, results in a wsdl parsing error with the following message: The HTML document does not contain Web service discovery information.

    From what I have discovered, the problem remains on parsing the wsdl:import statements which are included the wsdl because it is splitted into several wsdl files which are combined using the wsdl:import statement.

    The problem occurs in .Net 1.1 and .Net 2.0 with the following wsdl for example: http://wsdl.eu.clickandbuy.com/EMS/1.0/EMSbinding.wsdl

    Is this wsdl really invalid or is this an interop/compatibility problem? Is there a way to address this problem?

    Kind Regards,

    Mark Schmalohr

    Tuesday, November 15, 2005 11:10 AM


All replies

  • hi,

    my experience is that (as weird as this sounds) .Net can't consume WSDL definitions which contain
      1. XML-comments
      2. WSDL-import statements (although the observations here were a bit inconclusive)

    As a consequence, i have removed all XML-comments and WSDL-imports from my WSDLs.

    Both of these issues in consuming perfectly valid WSDL definitions with a .Net client are (IMHO) outrageous. To write WSDLs without XML-comments and (more importantly) WSDL-imports makes for far inferior structuring and readability.

    Would be very interested to hear about other experiences!


    Thursday, December 08, 2005 2:20 PM
  • Actually this is not related to the <wsdl:import> processing.  The problem is in the way information is returned from the http://wsdl.eu.clickandbuy.com/EMS/1.0/EMSbinding.wsdl: the WebResponse contain the wsdl document, but claims that its Content type is "text/html", it should be set to "text/xml".


    I am afraid that you have to download the document using IE along with all imports:




    And run wsdl on the local copies:

              wsdl emsbinding.wsdl ems.wsdl ems.xsd


    Or maybe you can convince the http://wsdl.eu.clickandbuy.com/EMS/1.0/EMSbinding.wsdl publisher/author to return the correct ContentType (text/xml).






    Thursday, December 08, 2005 3:17 PM
  • Elena,

    just to clarify: are you saying that if the content-type for this WSDL were correct, then there would be no issues? In other words, there are no issues with consuming WSDLs with either XML-comments and/or WSDL-imports?!


    Tuesday, December 13, 2005 11:10 AM
  • Thanks Elena. I wonder if any version of Visual Studio solves the problem, since it seems difficult that the author to return the correct ContentType
    Friday, December 23, 2005 12:44 PM

  • Hey everyone, I too have been on the verge of pulling my hair out when attempting to generate proxy files created from a WSDL file that is fragmented. It seems that this is the standard way the WSDL contracts are generated with IBM WebSphere and while it is completely valid WSDL and valid XML, it takes a bit of work to get WSDL to do it's job with fragmented files. Anyways, I've been doing some work for some clients that sent me severaly WSDL contracts to their Websphere web service so in order to deal with them, I've written my first PowerShell script to help me with this problem. Essentially you have to supply all external files referenced in the WSDL contract in the command line to wsdl.exe. So This helped me solve my problems, hope it helps others out there.

    # The following PowerShell script was created for the purpose of creating the necessary
    # C++ Header file containing Proxies built from WSDL from the WebSphere
    # -- Get the name of the primary WSDL file
    param($source_wsdl = $(throw "A source wsdl file must be specified."))

    # -- Ensure that $source_wsdl is defined correctly
    if ( [System.IO.File]::Exists($source_wsdl) -ne $true)
        throw "The file `"$source_wsdl`" does not exits."

    # -- Setup script variables
    $wsdl_exe_path = "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\wsdl.exe";
    $wsdl_exe = ".\wsdl /l:CPP";

    # -- Get the path of the source wsdl file
    $wsdl_path = [System.IO.Path]::GetDirectoryName($source_wsdl)

    # -- Wrap the source wsdl file name in quotes
    $source_wsdl = "`"$source_wsdl`""

    # -- Get all wsdl files recursively (as file objects)
    $wsdlFiles = ls $wsdl_path -recurse -exclude $source_wsdl -filter *.wsdl | ? { $_.FullName -ne $source_wsdl -and ($_.Mode.StartsWith("d") -eq $false) } | % { "`"$($_.FullName)`"" };

    # -- Get all xsd files recursively (as file objects)
    $xsdFiles = ls $wsdl_path -recurse -filter *.xsd | % { "`"$($_.FullName)`"" };

    # -- Copy the WSDL.EXE executable to the local folder
    copy-item -path $wsdl_exe_path -destination .;

    # -- Build the final command
    $command = "$wsdl_exe $source_wsdl $(`"$wsdlFiles`") $(`"$xsdFiles`")";

    # -- Run the command
    invoke-expression $command;

    # -- Remove WSDL.EXE
    remove-item ".\wsdl.exe";

    ############# DEBUG
    #write-output "-----------------------------------------------------------"
    #write-output "Command => $command"
    #write-output "WSDL Files => $wsdlFiles"
    #write-output "XSD Files => $xsdFiles"
    #write-output "-----------------------------------------------------------"
    ############# DEBUG

    To change the language that the proxies are produced in change the line
    $wsdl_exe = ".\wsdl /l:CPP";
    to whatever you'd like.

    Also note that there are several back-tick characters in the script that may not be represented properly when this post is represented as HTML. Anyways, I hope this saves some of your out there the fustration that I had attempting to understand what I was doing wrong and then finally having to build the wsdl.exe command yourself when you find out what you need to do.
    Monday, September 17, 2007 1:48 AM