murugamsm / xmlrpcnet Goto Github PK

Following exception is thrown during deserialization if the first argument
of a method call is specified as params

CookComputing.XmlRpc.XmlRpcTypeMismatchException : request contains int
value where array expected [request : parameter 1]

Performance from Smel:

I use CookComputing.XmlRpcV2.dll, and very slow working
*function XmlNode[] SelectNodes(XmlNode node, string name)
*in file XmlRpcSerializer.cs
original code
  XmlNode[] SelectNodes(XmlNode node, string name)
  {
    ArrayList list = new ArrayList();
    XmlNodeList nodes = node.ChildNodes;
    /*for (int i = 0; i < nodes.Count; i++)*/
    {
      if (*nodes[i]*.Name == name)   //exponent if i want 1000 node i need
go in node 1, after node 2, ... node 1000
        list.Add(nodes[i]);
    }
    return (XmlNode[])list.ToArray(typeof(XmlNode));
  }
you can changed on this
XmlNode[] SelectNodes(XmlNode node, string name)
  {
    ArrayList list = new ArrayList();
    XmlNodeList nodes = node.ChildNodes;
    /*foreach(XmlNode selnode in nodes)*/
    {
        if (selnode.Name == name)
            list.Add(selnode);               }
    return (XmlNode[])list.ToArray(typeof(XmlNode));
  }
in my program changet SelectNodes wokr <1sec, in original >10.

rTorrent uses <i8> type a lot. Current version of XML-RPC.NET always
returns 0 when the value is between <i8> tags. We could use Int64 (long)
for <i8> type.

When a call is made to an application returning an Array of Strings by a 
Windows Mobile application (CF Framwork) to a fullblown application, an 
Exception is raised (invalid type, implicit string expected Array) on the 
CF client.

Reported by Ben Lamb:

Thank-you for making your XML-RPC implementation for .NET freely available
and with such good documentation.

I’ve found a very minor bug.

The UseEmptyParamsTag property on the proxy doesn’t work unless you are
making asynchronous calls. Looking in XmlRpcClientProtocol.cs I can see
this flag is copied to the XmlRpcClienProcol object in the BeginInvoke
method but not the Invoke method. Inserting:

serializer.UseEmptyParamsTag = _useEmptyParamsTag;

At line 155 in this file fixes the problem.

Allows client to specify that either gzip and deflate compression by the
server is acceptable.

XmlRpcListenerService.ProcessRequest(...) catches any exception. But the
stream is only closed in the try - block. In some (exceptional) cases this
leads to an open stream, which is never closed. So the server rest in an
endless loop. Is it possible to add finally-block like this:

finally

{
RequestContext.Response.OutputStream.Close();

}

Overloaded methods are not current supported.

Add support for +00, +0000, -00, -0000

For example, two methods in this interface have been assigned the same
XML-RPC method name:

  interface IDupXmlRpcNames
  {
    [XmlRpcMethod("bad.Foo")]
    int Foo1(int x);
    [XmlRpcMethod("bad.Foo")]
    int Foo2(int x);
  }

We are using at the moment the version 2.3.2 of your library.

Some of my collegues like the autodocu - feature. They have now said that
this feature isn't working anymore. It seems that since we moved from
Hosting in .Net Remoting to HttpListener based hosting that the response is
not correct.

I found out the following thing:
The service is parsed correctly, and the XmlRpcDocWriter produces the
desired output. But: The content-length of the response is 0 (zero), the
response code is as expected 200. You can see it on this image (we use an
own build logfile-viewer)

am getting the following error when i tried to pass an enum as a parameter...
any help would appreciate...

CookComputing.XmlRpc.XmlRpcUnsupportedTypeException: A parameter is of, or
contains an instance of, type Aeturnum.Extenders.Common.FileState which
cannot be mapped to an XML-RPC

hi
  I have suggestion for STRUCT serialization. currenlty if i declare 
constants it will also serialize that.It should not do that and it should 
respect [NonSerializable] attribut just in case some one does not want a 
property or member to be included in struct serilaization. e.g

enum ResultEum{ Yes, No}
struct FOO
{
    [NonSerialiable]
    public ResultEnum result;
    public string Result{
       get 
         {
            return result.ToString();
         }
     }
}

To be specific i was using LISP .NET communication and i have to use 
struct withing .NET and also send to LISP and lisp only understand string. 
To do clean coding i use ENUM and other constants which is not possiable 
if the whole struct is serialize including constants. I want to control 
which memeber need to be serialized. 

Plz fix it or assing it to me I can fix this issue .

In XmlRpcSerializer.GetStructName function, it only go through the fields,
but not properties.

Scenario: XmlRpcMember attribute is used to "rename" a Property
Actual Result: XmlRpcMember for Property is not used when deserializing

Class XmlRpcSerializer throws a MissingMethodException with message "No
parameterless constructor defined for this object." in its ParseStruct
method if the XML-RPC value is being mapped to a .Net array. 

XmlRpcTypeMismatchException should be thrown.

Similarly if the struct or class being mapped to does not have a default
constructor.

I am using the library for communicating with industrial devices. Both have
a server and a client part. To be independant of an IIS or .Net Remoting I
implemented my server part using the XmlRpcListener class of the library 2.2.0.

The output of an request is o.k. instead that the value of content-length
in the HTTP header is always 0 (zero). The content length must be set
according to the xml-rpc specification. Also the clients do not accept the
responses with this header.

The value cannot be set in my class because:
1. content-length must be set BEFORE writing to the outputstream. Means
before the XmlRpcHttpServerProtocol class invokes Util.CopyStream();
2. RequestContext.Reponse.OutputStream is not seekable. That means it will
throw a "NotSupported exception" if you call get_length() on the stream.

At the moment I have made a workaround. I added a public field of type
HttpListenerContext to the XmlRpcHttpServerProtocol class. Then I can set
the contentLength property of the response just before the
Util.CopyStream() call.

In XmlRpcSerializer.GetStructName function, it only go through the fields,
but not properties.

Scenario: XmlRpcMember attribute is used to "rename" a Property
Actual Result: XmlRpcMember for Property is not used when deserializing

As per following request:

Our product is WPF based and is using .NET 3.5. MS just released 3.5 SP1
which contains the concept of a client profile which is a reduced
installation of .NET which contains the most common client assemblies. We'd
like to use this profile to reduce the download time of our application but
it appears as though XML-RPC.NET references System.Web which is not
contained in the client profile.

In our case we are only using the client portion of XML-RPC and don't have
a need for the server ( which I'm assuming the System.Web is used for ). Do
you think it'd be possible to pare down the build of XML-RPC to remove the 

In XmlRpcSerializer.GetStructName function, it only go through the fields,
but not properties.

Scenario: XmlRpcMember attribute is used to "rename" a Property
Actual Result: XmlRpcMember for Property is not used when deserializing

Some culture names have changed - this breaks one or more unit tests.

Change ntest/utils.c

Bugs reports by Mickael Gaillard:

I found 2 bug in your API (2.3.2)  for CF platform:

in XmlRpcSerializer.cs file at line 1793 :
    XmlNode SelectSingleNode(XmlNode node, string name)
    {
#if (COMPACT_FRAMEWORK)
      XmlNodeList nodes = node.ChildNodes;
      for (int i = 0; i < nodes.Count; i++)
      {
        // For "*" element else return null
        if ((name == "*") && !(nodes[i].Name.StartsWith("#")))
            return nodes[i];

        if (nodes[i].Name == name)
          return nodes[i];
      }
      return null;
#else
      return node.SelectSingleNode(name);
#endif
    }

in XmlRpcFaultException.cs at line 29
#if (!COMPACT_FRAMEWORK)
  using System.Runtime.Serialization;
#endif

This will provide support for XML-RPC api's where parameters are supplied
as members of a struct.

Enable client to specify whether strings values should be output as 

<value>text</value>

or

<value><string>text</string></value>

The default should remain as the second case.

Requests made by xml-rpc.net still contain <i4> even after following 2.21 
of the FAQ.

the system.net.webResponse class is implemententing the IDisposable 
interface.

But it' seems the dispose methode is never called.


This can cause crash when calling a lot of remote method in a short time

Email from Dan Terry:

Re: http://www.cookcomputing.com/blog/archives/000548.html

And: http://tech.groups.yahoo.com/group/XMLRPCNET/message/698 

I ran into the nasty “Operation could destabilize the runtime” issue this
evening when playing around with your library (client functionality only)
for the first time.  The issue is not related to the .NET 1.x version of
the library being loaded with into the .NET 2.0 runtime as earlier mentioned.



To reproduce the error, you simply need to make sure you are running with a
set of permissions that do not allow the library to SkipVerification.  To
do this and still be able to run the library, compile with the following
assembly attributes.



[assembly: FileIOPermission(SecurityAction.RequestMinimum,
AllLocalFiles=FileIOPermissionAccess.PathDiscovery)]

[assembly: ReflectionPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]

[assembly: WebPermission(SecurityAction.RequestMinimum,
Connect=@"http://someurl")]

[assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted = false)]



I am new to CAS (using Open Source is actually the reason I am trying to
learn it – no offense J), so this is a pretty crude set at the moment. 
These are pretty close to the minimum your library requires to run
(client).  Restricting Urls is probably overkill.  Anyways, I arrived at
this set of attributes from incrementally debugging and adding required
permissions to your library.  See article
http://msdn2.microsoft.com/en-us/library/d17fa5e4(vs.71).aspx.



Now, create a proxy using XmlRpcProxyGen.Create<T> and try to invoke a
method (no use of async begin/end/etc) on the proxy.  At this point, the
runtime will attempt to verify the MSIL in the assembly you have
dynamically created.  You will get the “Operation could destabilize the
runtime” VerificationException.



To prove that this is the case compile with:



[assembly: SecurityPermission(SecurityAction.RequestMinimum,
SkipVerification=true)]



With this attribute, no verification = no exception.



An article that helped along the way
http://blogs.msdn.com/haibo_luo/archive/2006/10/31/always-peverify-il-code-of-yo
ur-dynamic-method.aspx.



So next, I used the XmlRpcProxyGen.CreateAssembly method to save a dynamic
assembly to disk.  Peverify reveals the following error:



[IL]: Error: [c:\someassembly.dll : someinterface::somemethod][offset
0x00000012][found ref 'System.Reflection.MethodBase'][expected ref
'System.Reflection.MethodInfo'] Unexpected type on the stack.

1 Error Verifying c:\someassembly.dll



Looking at XmlRpcProxyGen.cs you can see that lines 184-189 are suspect.



// call Invoke on base class

Type[] invokeTypes = new Type[] { typeof(MethodInfo), typeof(object[]) };

MethodInfo invokeMethod

  = typeof(XmlRpcClientProtocol).GetMethod("Invoke", invokeTypes);

ilgen.Emit(OpCodes.Ldarg_0);

ilgen.Emit(OpCodes.Call, typeof(MethodBase).GetMethod("GetCurrentMethod"));



I am a Reflection super newb so I may be completely off base; however, it
appears that the result of MethodBase.GetCurrentMethod (which returns a
MethodBase) is being later passed (not shown) as a MethodInfo without an
explicit cast in the MSIL (I took a brief look at the MSIL using ILDASM,
and I have also Reflected the class - Reflector shows an explicit cast that
the MSIL does not have).



Anyways… that is a lot for now.  Sorry for the poor grammar and style – its
very late here.  Hopefully this is plenty of information to make a fix.  I
believe that changing line 185 of XmlRpcProxyGen to have typeof(MethodBase)
instead of typeof(MethodInfo) will fix the problem (of course you would
have to change for all of the Async BuildMethods also).  I am wondering how
you can make the assumption that MethodBase returned from
MethodBase.GetCurrentMethod() can be cast to MethodInfo?  That is my final
question.

This is a connection to Drupals XmlRpc service.

What steps will reproduce the problem?
1. Basic Code: 
    public interface IDrupalXmlRpc
    {
        [XmlRpcBegin("system.connect")]
        IAsyncResult BeginConnect(AsyncCallback acb);

        [XmlRpcEnd]
        Drupal EndConnect(IAsyncResult asr);
    }

    public class BaseClass<T> where T : IXmlRpcProxy
    {
        public T Service { get; set; }

        public void IntilializeService()
        {
            Service = XmlRpcProxyGen.Create<T>();
        }
    }

    [XmlRpcUrl("http://www.mysite.com/?q=services/xmlrpc")]
    public interface IMolineDrupalService : IXmlRpcProxy, IDrupalXmlRpc
    {
    }

    public class DevMoline : BaseClass<IMolineDrupalService>
    { ...}

;Button Event
        private void btnGo_Click(object sender, EventArgs e)
        {
            try
            {
                dev = new DevMoline();
                dev.IntilializeService();

                 AsyncCallback acb = new AsyncCallback(ConnectionCallBack);
                 dev.Service.BeginConnect(acb);

            }
            catch (Exception)
            {

                throw;
            }
        }


2. What is the expected output? What do you see instead?
When the "dev.Service.BeginConnect(acb)" method is called, you receive the
following error: 
Shouldn't the IAsyncResult method of "BeginConnect" inherit as well as
"EndConnect"?

Error: Method 'BeginConnect' in type
'XmlRpcProxy4b5de82f-45cb-4ce6-80e0-1f67a6f69684' from assembly
'XmlRpcProxy4b5de82f-45cb-4ce6-80e0-1f67a6f69684, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null' does not have an implementation.

For this to work, I need to add "new  IAsyncResult BeginConnect..." to the
IMolineDrupalService interface.

Throw new exception type XmlRpcDupXmlRpcMethodNames.

Post to XMLRPCNET group from Denis Jakovlev

I attempt to write Xml-rpc Server under Mono. And it encountered this
problem. With the demand from the client I obtain here this error -
"Cannot be changed after headers are sent."

What steps will reproduce the problem?
A call to this kind of XmlRpcMethod:
 [XmlRpcMethod]
 public object Method2(object arg0, params object[] args)

Problem:
This method caused application crash under Mono/Linux but not MS.NET/Windows.

Please consider this patch:

@@ -157,7 +157,8 @@
               if (i >= pis.Length)
                 throw new XmlRpcInvalidParametersException("Number of request "
                   + "parameters greater than number of proxy method parameters.");
-              if (Attribute.IsDefined(pis[i], typeof(ParamArrayAttribute)))
+              else if (i == pis.Length - 1 &&
+                Attribute.IsDefined(pis[i], typeof(ParamArrayAttribute)))
               {
                 Array ary = (Array)request.args[i];
                 foreach (object o in ary)

Explanation:
This looks like more of a Mono problem instead of a XML-RPC.NET problem but I 
think at least the check of ParamArrayAttribute on every 
parameter is unnecessary as the compiler only allows the "params" keyword to be 
applied to the last one.

Problem is caused by the default value (false) of
XmlDocument.PreserveWhiteSpace being used.

C:\xmlrpc\bin>sn -v cookcomputing.xmlrpcv2.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 2.0.50727.42
Copyright (c) Microsoft Corporation.  All rights reserved.

cookcomputing.xmlrpcv2.dll does not represent a strongly named assembly

But its ok for the .Net 1.0 compatible assembly:

C:\xmlrpc\bin1_0>sn -v cookcomputing.xmlrpc.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 2.0.50727.42
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'cookcomputing.xmlrpc.dll' is valid

Hello. I'm having problem with serializing struct that contains non
XML-RPC-valid field types but with NonSerializedAttribute set. I think that
XmlRpcServiceInfo class should allow such cases.

For example it should allow serializing of this:

public struct Test 
{
  [NonSerialized]
  public long NonXmlRpcValidButNotSerialized;
  public int XmlRpcValidAndSerialized;
}

Attached a .patch that corrects XmlRpcServiceInfo behaviour.

Bug from Jonathan Shore:

Discovered one bug related to an XML-RPC request for a void method.   The
returned XML is:

<?xml version="1.0"?>
<methodResponse>
  <params/>
</methodResponse>

in response to calling some void method, such as:

        interface foo
        {
                void  dosomething (...)
        }

It all works well until line 205 in XmlRpcClientProtocol, where you attempt
to dereference resp.retVal.   resp will be null when a void method is
called.   Should read:

        reto = resp != null ? resp.retVal : null;

rather than:

        reto =  resp.retVal 

Following line does not compile for 1.0 Framework:

httpReq.ServicePoint.Expect100Continue = _expect100Continue;

Investigate why this built before and decide whether to remove the ability
to set this in 1.0 build or whether lowest supported version of Framework
will be 1.1

Add to FAQ

Fault response: 0 Method GetStateName in type StateNameServer has duplicate
XmlRpc method name examples.getStateName Server returned a fault exception:
[0] Method GetStateName in type StateNameServer has duplicate XmlRpc method
name examples.getStateName

Resolution: methods in implementation should not be attributed with
XmlRpcMethod.

[deleted issue]

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Deserializing the following causes a NullReferenceException:

<methodCall>
  <methodName>Linisgre</methodName>
  <params>
    <param/>
  </params>
</methodCall>


Should throw an XmlRpcInvalidXmlRpcException

we need some times to return some values with <nil/>, thats not in xml-rpc
standard but have to be in xml-rpc extension.

we fixed our client with this diff:

--- XmlRpcSerializer.cs   2008-09-19 14:32:01.000000000 +0200
+++ XmlRpcSerializer.cs 2008-04-30 08:56:44.000000000 +0200
@@ -867,10 +867,6 @@
           ParsedType = typeof(DateTime);
           ParsedArrayType = typeof(DateTime[]);
         }
-        else if (node.Name == "nil")
-        {
-            return "";
-        }
       }
       return retObj;
     }

i don't really know if this is the right solution for this problem.

Enhance XmlRpcClientProtocol class to provide access to HTTP response headers.

Fix null object exception if get request stream fails when logging.

Two cases of:

reqStream.Close();

in XmlRpcClientProtocol.cs.

Email from Leif Opseth:

I've recently written some code using the excellent XML-RPC.NET library.
However, I ran into an XML-RPC server that required a small change to the
XML-RPC.NET source code to work, and I'm wondering if this issue could be
something that the 'official' XML-RPC.NET source also should address.

The issue is as follows:

The original xml-rpc.net code sends parameter data for functions that has
no parameters as an empty 'params' tag, i.e. as:
--
<methodCall>
       <methodName>some_function</methodName>
       <params />
</methodCall>
--

The XML-RPC server in question does not handle this empty tag, and require
these no-parameter functions to be encoded without the empty tag, e.g. as:
--
<methodCall>
       <methodName>some_function</methodName>
</methodCall>
--

My fix to the XML-RPC.NET source was to simply check for non-zero number
of params before applying the 'params' tag in the 'SerializeRequest'
function in 'XmlRpcSerializer.cs'.

After reading the XML-RPC specification, I can't find that the empty
'params' tag is a requirement, so in theory the XML-RPC server does
nothing wrong (although it could of course be more versatile).

I would think that there could be other servers out there that could have
a similar implementation, and I think that simply adding something like a
'UseEmptyParamsTag' property to e.g. the XML-RPC.NET's 'IXmlRpcProxy'
interface, would make the XML-RPC.NET library more robust for different
implementations. A default value for this property set to 'true' will make
the library code compatible with code that currently uses XML-RPC.NET.
Setting this property to 'false' will solve my current server issue.

This will result in stack overflow.

        [Test]
        public void DBNull() {
            DBNull value = DBNull.Value;
            Type type = value.GetType();
            XmlRpcServiceInfo.GetXmlRpcType (type);
        }

Servers sometimes return complex responses containing structs where it not
possible to represent the response as a .NET type. For example in the
response below the array contains items of type boolean and array of
structs. The structs will be mapped to type XmlRpcStruct.

In cases like this it would be useful to be able to deserialize an
XmlRpcStruct into a .NET type to avoid having to unpack the XmlRpcStruct
manually.

<?xml version="1.0" encoding="utf-8"?>
<methodResponse>
  <params>
    <param>
      <value>
        <array>
          <data>
            <value>
              <boolean>1</boolean>
            </value>
            <value>
              <array>
                <data>
                  <value>
                    <struct>
                      <member>
                        <name>id</name>
                        <value>
                          <string>1</string>
                        </value>
                      </member>
                      <member>
                        <name>name</name>
                        <value>
                          <string>Brand Nummer 1</string>
                        </value>
                      </member>
                    </struct>
                  </value>
                  <value>
                    <struct>
                      <member>
                        <name>id</name>
                        <value>
                          <string>2</string>
                        </value>
                      </member>
                      <member>
                        <name>name</name>
                        <value>
                          <string>Brand Nummer 2</string>
                        </value>
                      </member>
                    </struct>
                  </value>
                </data>
              </array>
            </value>
          </data>
        </array>
      </value>
    </param>
  </params>
</methodResponse>

in order for a rpcserivce registered through remoting it must be dervied 
from MarshalByRefObject but XmlRpcServerProtocol not dervied which mean 
that my service will not have the rpc stander info methods. currely  
XmlRpcServerProtocol is drived from System.Object.

thanks

Traced the problem to this code XmlRpcHttpServerprotocol.cs
lines 71-74
if (!httpResp.SendChunked)
{
httpResp.ContentLength = responseStream.Length;
}


httpResp.SendChunked leads to
XmlRpcHttpResponse.cs
lines 47-51
bool IHttpResponse.SendChunked
{
get { throw new NotImplementedException(); }
set { throw new NotImplementedException(); }
}


httpResp.ContentLength leads to
XmlRpcHttpResponse.cs
lines 65-69
Int64 IHttpResponse.ContentLength
{
get { throw new NotImplementedException(); }
set { throw new NotImplementedException(); }
}

From Maxim Mironenko:

I found place in you code with "System.NullReferenceException was
 unhandled"
 at CookComputing.XmlRpc.XmlRpcSerializer.ParseHashtable(XmlNode node, Type
valueType, ParseStack parseStack, MappingAction mappingAction)
 in XmlRpcSerializer.cs:line 1317

   string rpcName = nameNode.FirstChild.Value;

 This happens when struct member looks like this:
<member>
 <name></name>
 <value>
   <string>Blah-blah</string>
 </value>
</member>

 For repeating this problem try to create an array with "" (empty
 string) key for value in PHP, like this:

 $fail_array = array (
     'tablename' => 'node',
     'field' => 'status',
     '' => 'Blah-blah',
     'value' => '1');

 And when you try to transfer this array via XML-RPC you will get
 this error.

Add support for HttpListener for hosting XML-RPC service in any process.