A: 

It doesn't look like your problem at this point is related with the SOAP Header at all... that "Computer name could not be obtained" error comes from somewhere else.

What are you specifying on the client as the service URL? Is the service running on the same machine as the client, or a different one? Is the service working with other, non-WCF clients?

tomasr
The url for the client is "http://MyServer/Services/Service1.asmx." For development the client is running on the same machine as the service. However, in production it will not be. I have a feeling in my gut that this is an environmental issue and not a WCF issue, but it would be great if we could run the service and client on the same box for development/testing purposes. The service does work fine with non-WCF clients.
Adam
Since both are on the same machine, does it work if you specify the URL with localhost instead of MyServer? Sounds like a DNS issue might be getting in the way.
tomasr
Just tried switching the endpoint to localhost. Same exception.
Adam
I'm staring to think this is environmental with our development machine. Going to try and deploy the services on another machine and hit it from the client separately.
Adam
Out of curiosity, can you use netstat -a to see what IP addresses the server (IIS?) is listening on? Then use nslookup to see how name resolution is working. Also, are there any proxies involved here? or maybe security software getting in the way?
tomasr
@tomasr I had to expand my command prompt buffer to 9999 to be able to see all of the data returned by the netstat -a. I'm not sure what to get out of this, but I see that the address I am hitting is in the listening state. Local address: dev-dc:40570 -> Foreign Address: dev-dc.dev.local:0 -> State: Listening. nslookup returns Server: Localhost Address: 127.0.0.1 and Name: dev-dc.dev.local Address: 192.168.131.66. Also this is a virtual machine domain controller running server 03 for sharepoint 2007 development.
Adam
Interesting... can you navigate to the asmx help page from the browser directly in the VM? What is the proxy configuration in IE?
tomasr
@tomasr no proxy. Yes navigable via browser though WSDL is unavailable because of sharepoint (we dont generate the <service>wsdl.aspx pages). Works as both http://dev-dc:40570/<service path> and http://localhost:40570/<service path>
Adam
You got me there, then, no clue what might be causing the issue. Only thing I'd maybe try is exclude the paths from sharepoint to avoid it messing with it; but other than that, maybe check with something like TcpTrace or similar tool to see if WCF is even trying the request...
tomasr
@tomasr Yea, just deployed this to a staging environment to test it out and it doesn't work. Same exception, not environmental. My next guess would be that sharepoint is causing it somehow. I appreciate your help.
Adam
A: 

Based on another question I just answered (about reading out SOAP headers), this approach should work for your requirement of including a SOAP header when calling an ASMX service from a WCF client:

Service1SoapClient client = new Service1SoapClient(binding, address);

using(OperationContextScope scope = new OperationContextScope(client.InnerChannel))
{
    // set the message in header
    MessageHeader header = MessageHeader.CreateHeader("MyHeader", "urn:Sample-NS", "Some Value");
    OperationContext.Current.OutgoingMessageHeaders.Add(header); 

    string expected = client.MyMethod(new MyCustomSoapHeader(){SomeProperty = true});
}

I hope this works - I don't really have the infrastructure at hand to test this right now...

marc_s
@marc_s Just tried this out. Same exception. Can you explain the parameters of the CreateHeader method? Maybe I put the wrong thing there in my actual implementation. Mine looks like MessageHeader.CreateHeader(_header.GetType().Name, "urn:Sample-NS", _header);
Adam