Null Response in VS2008

Version 1
    This document was generated from CDN thread

    Created by: Jeremy Sanders on 22-05-2009 07:43:33 PM
    I compiled the AXLAPIService into a C# DLL with VS2008 and referenced it from a VB project. I can create the class instance and run the methods. I even see the request and valid response in the RTMT logs. I just get a null object passed back into my vb project. I even debugged into the AXPAPIService.dll and the null is being passed back from SoapHttpClientProtocol.Invoke. Any ideas on how to track down where the disconnect is?

    Subject: RE: New Message from Jeremy Sanders in Administration XML (AXL) - Administr
    Replied by: Alex Hannah on 22-05-2009 07:46:40 PM
    I to have the same problem, please let me know what you find. 



    Alex Hannah, CCVP, CCSI #32072
    Solutions Engineer
    TBL Networks, Inc.

    SNR <http://www.theblinkylight.com/snr> : (804) 822-3661
    (How many numbers do you have? <http://www.theblinkylight.com/snr> )
    ahannah@tblnetworks.com <mailto:ahannah@tblnetworks.com>

    [download my v-card <http://www.tblnetworks.com/signature/ahannah.vcf> ]

    NEWS: TBL Support Model Featured in Cisco Case Study. Read it HERE. <http://www.theblinkylight.com/news/ciscocasestudy.aspx>





    From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
    Sent: Friday, May 22, 2009 3:44 PM
    To: cdicuser@developer.cisco.com
    Subject: New Message from Jeremy Sanders in Administration XML (AXL) - Administration XML Questions: Null Response in VS2008



    Jeremy Sanders has created a new message in the forum "Administration XML Questions":
    --------------------------------------------------------------
    I compiled the AXLAPIService into a C# DLL with VS2008 and referenced it from a VB project. I can create the class instance and run the methods. I even see the request and valid response in the RTMT logs. I just get a null object passed back into my vb project. I even debugged into the AXPAPIService.dll and the null is being passed back from SoapHttpClientProtocol.Invoke. Any ideas on how to track down where the disconnect is?
    --
    To respond to this post, please click the following link:
    <http://developer.cisco.com/web/axl/forums/-/message_boards/message/1389460>
    or simply reply to this email.

    Subject: RE: New Message from Jeremy Sanders in Administration XML (AXL) - Administr
    Replied by: Jeremy Sanders on 26-05-2009 03:08:47 PM
    Alex, are you using VS2008 on Vista or XP? I wonder if it has something to do with the .Net library on Vista? (that's what I'm currently using).

    Subject: RE: New Message from Jeremy Sanders in Administration XML (AXL) - Administr
    Replied by: Jeremy Sanders on 05-06-2009 12:42:10 AM
    I found this article:
     
    http://bytes.com/groups/net-web-services/431353-how-diagnose-soaphttpclientprotocol-invoke-failures
     
    and this document that looks like it could be used to debug the process that .Net is using to deserialize the soap message
     
    [url=http://msdn.microsoft.com/en-us/library/esw638yk(VS.71).aspx]http://msdn.microsoft.com/en-us/library/esw638yk(VS.71).aspx
     
    Someone let me know if you have already fixed this, either by modifying the WSDL. It appears that you can import the WSDL as a service reference, but then it doesn't look anything like the sample code. It is in the new WCF format of VS2008. I guess another option would be to find an older copy of wsdl.exe and use it to create the client proxy class...
     
    Any suggestions?

    Subject: RE: New Message from Jeremy Sanders in Administration XML (AXL) - Administr
    Replied by: Jonathan Withers on 08-06-2009 12:50:31 PM
    I have had the same issue. It's well worth using a tool like Fiddler http://www.fiddler2.com/fiddler2/ so that you can debug the request/response that are sent to the Call Manager. After analysing the details i found out that the namespace in the response was different to the request.

    Subject: RE: New Message from Jeremy Sanders in Administration XML (AXL) - Administr
    Replied by: Gary Springer on 19-06-2009 01:18:11 AM
    I have had the same issue. It's well worth using a tool like Fiddler http://www.fiddler2.com/fiddler2/ so that you can debug the request/response that are sent to the Call Manager. After analysing the details i found out that the namespace in the response was different to the request.

     
    I just resolved this same problem, the namespace between the request and the response were different.  What was odd was, the namespaces matched up fine on production but in development the response namespace was different, resulting in "null" objects.
     
     

    Subject: RE: New Message from Jeremy Sanders in Administration XML (AXL) - Administr
    Replied by: David Staudt on 19-06-2009 02:18:27 AM
    When AXL was first released, it did indeed return the wrong Namespace.  This was corrected in later releases, but was made optional for backward compatibility reasons - some apps had been built around the invalid Namespace.  There is a service parameter that enables/disables this fix: Service Parameters/Cisco Database Layer Monitor (Advanced)/Send Valid Namespace in AXL Response.
     
    This could explain why the behaviour changed from site to site.

    Subject: RE: New Message from Jeremy Sanders in Administration XML (AXL) - Administr
    Replied by: Jeremy Sanders on 19-06-2009 04:52:12 AM
    See anything in the attached file that would cause the null response?

    Subject: RE: New Message from Jeremy Sanders in Administration XML (AXL) - Administr
    Replied by: David Staudt on 19-06-2009 06:07:20 AM
    The problem with <executeSQLQuery> is that the data that is returned is not of fixed schema format.  In the .xsd, the type is xsi:any - meaning XML of any possible format is possible as a return.  This is due to the nature of SQL: the data returned can have variables fields, of variable data types, etc.  It is not possible for the WSDL compiler (.NET or Axis2) to auto-generate static code to handle the free form data. 
     
    I highly suspect .NET is also unable to handle the free-form data type here as well.
     
    About the best advice I have seen so far, is to use 'manual' XML parsing to handle <executeSQLQuery>, and use the WSDL auto-generated code for everything else.