WP-XML-RPCLib2

　ある事にハマって、久しぶりに寄らせて頂きました。

　LINQ To XMLで書き換えられたそうで、ソースがスッキリしましたね。ありがたく使わせていただきます。

　で、ハマっていたのは、
　
　Aと言うServerのMTにはXML-PRC経由でAPI操作が可能(日本語変？)しかし、同じバージョンでもBと言うServerではエラーになりました。

　Serverのせいと投げ出しても良かったのですが、Firefoxの拡張機能のScribefoxだとA,B両方のServerに対してAPI操作が可能です。

　パケットモニタで中身を見たのですが、一見、同じバイナリーコードを送信していたので、3日ほど悩みました。

　やっとこ、判明したのは、リクエストを作成する際に、エンコードを指定するとBOMが付加され、BサーバーのXMLパースでエラーが出ていました。

　もうひとつ、MT3.33-jaしか試していないのですが、上記のようなエラーですと、faultCodeに「Client」と文字列が入りますので、XmlRpcIntにキャストするとエラーになります。

　又、MTだけだと思いますが、faultStringもBase64で返ってきますので、XmlRpcValueのタイプを判断してキャストしないとエラーになりました。

　少しでもご協力出来ればと思い報告させて頂きました。
　
　

お久しぶりです。ご指摘大変助かります。
指摘を受けて差し替えを行いました。
・BOMの問題について
そもそもEncodingをUTF-8に決めうちしている今のやり方は良くないだろうということで、コンストラクタからEncodingを渡せるように変更しました。
BOM無しを指定する場合は、new UTF8Encoding(false)を渡してみてください。
・faultCode、faultString
それぞれint、stringであることがXML-RPCの仕様で決まっていますので、その仕様から逸脱していることを明示的に示す例外を吐くように変更しました。
どうしてもXmlRpcValue型で取得したい場合は、ソースコードに直接手を入れて下さい。

しかしBOMの問題ですか･･･。よく特定できましたね。お疲れ様です。

　早速の差し替えありがとうございます。

　faultCode, faultStringはMTの挙動がおかしいとは言え、発生して初めて分かる問題なので偶然とは言え報告出来て良かったです。

　BOMの問題は、Scribefoxと送信内容の何が違うのか、パケットモニタの結果をバイト毎に比較して見つけました。

　.NetでのXML-PRCはCook Computingが有名ですが、スッキリ度や敷居の低さなどはコチラの方が絶対上だと思っています。

　応援していますので、これからも頑張って下さい。

　では、