Problems moving an web service to another server - asp.net

Question

I have C#/ASP.NET web service which is running on a remote server and uses WSDL. It worked fine up until recently when it was moved to another server. However this means I had to change the database connection string, which was hard coded, so the code needed to be rebuilt on my development machine and uploaded to the server.
The service is called from a PHP script running on another web server using SOAP.
For some reason, from what I can tell, it's trying to run the old code, even though I've modified it.
e.g. if I change my web service function to just return, for example, "Hello, World", it seems to still try to connect to the database, etc. (but failing because that database no longer exists, I believe it's still trying to use the old connection string)
If I remove the function, it tells me that the function doesn't exist. (So it is looking in the right place)
If I add a new function and try to call it from the php script, I get the error
The server did not recognize the value of HTTP Header SOAPAction
If I try and test it on the actual server using the http://localhost/Myservice/Myservice.asmx everything works fine!
Here is the code I am using to call:
ini_set("soap.wsdl_cache_enabled", 0);
$client = new SoapClient("http://1.2.3.4:8083/MyService/MyService.asmx?WSDL&revision=1", array('cache_wsdl' => WSDL_CACHE_NONE));
$input = new stdClass;
$input->inputvals = '15707F';
echo "Functions: |";
print_r($client->__getFunctions()); // Lists all functions including new ones
echo "|\n\n";
$Response = $client->checkPrice($input);
print_r($Response);
To deploy the code this is what I'm doing - on local development machine, I Publish the solution to File System (for some reason I can't get IIS working on this machine). Then stop IIS on server machine, "Remove Application" in IIS, copy my files in, "Convert to Application", then restart IIS.

Answer 1

The server seems to get a wrong SOAPAction HTTP-Head attribute (which is part of the SOAP-standard) from your SOAP-Client. Check the wsdl for the expected one (wsdl:binding section) and make sure that you're sending it with the expected value.

Answer 2

OK, I'm not completely satisfied with this solution but here is how I got it working.
I don't know enough about WSDL to know why or how this happens, but the WSDL xml file had the following lines in it (as per my comment on my own original post).
<wsdl:service name="Myservice">
<wsdl:port name="MyserviceSoap" binding="tns:MyserviceSoap">
<soap:address location="http://1.2.3.4/Myservice/Myservice.asmx" />
</wsdl:port>
.
.
.
</wsdl:service>
Note the lack of the :8083 port on the location. Originally I had moved the service from 1.2.3.4 to 1.2.3.4:8083 in order to keep it running during the transition - the router then uses NAT to forward it to the correct server on their internal network. When the owners of the server had said they turned off, all they had turned off was the MS SQL server on that computer, so my old web service was still working away. (I had kind of taken their word for it when they said they had turned off the server)
To work around this, I overrode the __doRequest() function in the SoapClient class in my PHP client script to manually add the :8083 to the URL of the location.
class SoapClient8083 extends SoapClient
{
public function __doRequest($request, $location, $action, $version, $one_way = 0) {
$location_parts = explode("//", $location);
if (count($location_parts) == 2) {
$location_url_parts = explode("/", $location_parts[1]);
$location_url_parts[0] .= ":8083";
$new_location = $location_parts[0] . "//" . implode("/", $location_url_parts);
}
if (isset($new_location) && $new_location)
$location = $new_location;
return parent::__doRequest($request, $location, $action, $version, $one_way);
}
}
So it was getting the function list from the correct place which was why it was correctly recognising when I removed the function, but then contacting the wrong place to actually implement the functions.
... 8 hours of trying to debug later ...
Anyway, I'd rather not stick with this solution and instead figure out why the WSDL doesn't put the port number on the <soap:address location... />
Thanks for the responses - they did encourage me to look in the right direction...