I have this web service I want to use. The supplier only provides a PHP example to use the API. It is not a standard SOAP or REST service, but a custom Http POST based command. This means that you that you either have to write
http://www.asp.net/downloads/archived/migration-assistants/php-to-aspnet/
Because I had no Visual Studio installed, ready to be launched, i used the command line conversion.
C:\Program Files\Microsoft Corporation\PHP to ASP.NET Migration Assistant>PHPConvert.exe "c:\source\PhpSource" /out "C:\source\AspDotNetVersion”
The port of the code was successful. Most of the code was converted to c#. A lot of conversion warnings popped up, but most of them where not imposing any severe problems.
Code clean-up
A manual code clean-up is advised. For example, this code comes clearly from an unmanaged environment:
- dpublic virtual void useSecure(bool val)
- {
- if ((val == true) && (val.GetType() == true.GetType()))
- {
- this.Secure = true;
- }
Why should you check the type of “val” at runtime? This is already done by the compiler. A simple “ if (val== true) “ would be sufficient. Or in this case even shorter:
- d public virtual void useSecure(bool val)
- {
- this.Secure = val;
- }
Other things to clean up are links to magic-quotes, cURL and other specific PHP stuff.
Calling the API
Calling the API means in PHP that you do a socket write and read. For example, in PHP one would do:
$sock = fsockopen("ssl://".$this->ApiUrl["host"], 443, $errno, $errstr);
Because every effort is done to maintain the original architecture by the conversion tool. The convertor tool added a PHP namespace containing extra support classes for duplicating the original (php) functionality. The previous line of code is thus converted to:
sock = PHP.NetworkSupport.OpenSocket("ssl://" + this.ApiUrl["host"], 443, errstr);
The OpenSocket function is a wrapper function with one line (with some additional simple error handling):
returnValue = (System.Net.HttpWebRequest)System.Net.WebRequest.Create((System.String)Target); // + ":" + System.Convert.ToInt32(Port));
Although this is neat, I like the native .Net HttpWebRequest and HttpWebResponse Classes. So I took the code from my previous blog post: Http Post using C#, adapted it a bit and removed almost 80 lines of the converted code.
My problem with the wrapper functions created by the convertor tool, is that they use System.Object parameters and also return a System.Object. So for readability and maintenance reasons, I started immediately converting this to some strongly typed code.
Conclusion
I was very pleased with this tool. I saved literally hours typing, and it took me (only) a few hours of refactoring. Refactoring meant:
- removing unused functionality (magicQuotes, cURL, …)
- removing unnecessary type checks using Relfection
- removing calls to wrapper functions when I had decent managed .Net code available in my library
And just now I started thinking that it may have been faster implementing a custom WCF implementation.
Subscribe