views:

1340

answers:

5

I've written a fairly simple little C# web service, hosted from a standalone EXE via WCF. The code - somewhat simplified - looks like this:

namespace VMProvisionEXE
{
class EXEWrapper
{
    static void Main(string[] args)
    {
        WSHttpBinding myBinding = new WSHttpBinding();
        myBinding.Security.Mode = SecurityMode.None;

        Uri baseAddress = new Uri("http://bernard3:8000/VMWareProvisioning/Service");
        ServiceHost selfHost = new ServiceHost(typeof(VMPService), baseAddress);

        try
        {
            selfHost.AddServiceEndpoint(typeof(IVMProvisionCore), myBinding, "CoreServices");

            ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
            smb.HttpGetEnabled = true;
            smb.MetadataExporter.PolicyVersion = PolicyVersion.Policy12;
            selfHost.Description.Behaviors.Add(smb);

            // Add MEX endpoint
            selfHost.AddServiceEndpoint(ServiceMetadataBehavior.MexContractName, MetadataExchangeBindings.CreateMexHttpBinding(), "mex");

            selfHost.Open();
            Console.WriteLine("The service is ready.");
            Console.ReadLine();

The rest of the C# code; the class VMPService above implements VMProvisionCore.IVMProvisionCore.

namespace VMProvisionCore
{
[ServiceContract(Namespace = "http://Cisco.VMProvision.Core", ProtectionLevel = System.Net.Security.ProtectionLevel.None)]
public interface IVMProvisionCore
{
    [OperationContract]
    bool AuthenticateUser(string username, string password);
}

I can easily create a Visual Studio 2008 client application that consumes this service. No problems. But using Delphi 2007 is a different issue. I can use the WSDL importer in Delphi to retrieve the WSDL from (in this case) http://bernard3:8000/VMWareProvisioning/Service?wsdl The import unit compiles just fine. I have to initialize the proxy by hand since the WSDL doesn't contain a URL (notice the extra "/CoreServices" as shown in the C# code):

var
  Auth: AuthenticateUser;
  AuthResponse: AuthenticateUserResponse;
  CoreI: IVMProvisionCore;
begin
  CoreI:= GetIVMProvisionCore(False, 'http://bernard3:8000/VMWareProvisioning/Service/CoreServices');
  Auth:= AuthenticateUser.Create;
  try
    Auth.username:= 'test';
    Auth.password:= 'test';
    AuthResponse:= CoreI.AuthenticateUser(Auth);
  finally
    FreeAndNIL(Auth);
  end;

The above code will generate an error when it hits the "CoreI.AuthenticateUser(Auth);". The error is "Cannot process the message because the content type 'text/xml; charset="utf-8" was not the expected type 'application/soap+xml; charset=utf-8."

I suspect that I've got a stupid little error somewhere, perhaps during the import of the WSDL or in the connection options or something. Can anyone help?

A: 

I have also faced same problem when consuming C# web service in delphi.
Delphi 7.0/2005/2007 does not support new WSDL definitions.
For this, you will need to download latest WSDL Importer (WSDLImp.exe). It will also provide source code for updated delphi source code pass files.

Sumit Deo
Do you know where I can download the latests WSDLImp.exe? I checked the Embarcadero web site, but couldn't find anything beyond bug fix references to it.
Jason Swager
+1  A: 

This is caused by a SOAP version mismatch. The C# service is expecting a SOAP12 message and receiving a SOAP11 message from your Delphi app. Depending on your situation you need to change either of the two sides. I can't really comment on the Delphi side. On the WCF side you can use the BasicHttpBinding which defaults to SOAP11 or, if you need more control, use a CustomBinding specifying a message type of SOAP11.

Maurice
Switching the C# server to BasicHttpBinding indeed solved the application/soap+xml problem. However, it opened up a whole bunch of new errors: blank SOAPAction values, parameters not being read. I'm working on those now.
Jason Swager
I have had a less then perfect score on WCF interop with other environments. SOAP11 seems to be less interopable then SOAP12 so if your Delphi code allows you to switch to SOAP12 easily I would suggest exploring that option.
Maurice
+1  A: 

Found the solution. It's multiple parts and requires a few changes to the C# side, more to the Delphi side. Note that this was tested with Delphi 2007 and Visual Studio 2008.

C# side: Use BasicHttpBinding rather than WSHttpBinding.

Fix Step 1

BasicHttpBinding myBinding = new BasicHttpBinding();
myBinding.Security.Mode = BasicHttpSecurityMode.None;

This change will resolve the application/soap+xml errors on the Delphi side.

Delphi 2007 side: Running against the modified C# web service will now generate errors like this:

Exception class ERemotableException with message 'The message with Action '' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).'

To resolve this problem, add SOAPActions to all your supported interfaces. Here's the example from my code; this must be done AFTER all of the InvRegistry changes made by the import-from-WSDL-PAS-file's initialization section:

Fix Step 2

InvRegistry.RegisterDefaultSOAPAction(TypeInfo(IVMProvisionCore), 'http://Cisco.VMProvision.Core/CoreServices/%operationName%');

The type name and URL should be obtainable from the Delphi generated import file from the WSDL and/or an inspection of the actual WSDL. The above example was for my own project. After these code changes, then you'll the error:

Exception class ERemotableException with message 'The formatter threw an exception while trying to deserialize the message: Error in deserializing body of request message for operation....

This error is resolved by adding the following code (credits to http://www.bobswart.nl/weblog/Blog.aspx?RootId=5:798). Again, this new code must be after all the InvRegistry stuff in the initialization of the WSDL-to-PAS file.

Fix Step 3

InvRegistry.RegisterInvokeOptions(TypeInfo(IVMProvisionCore), ioDocument);

At this point, packets will go back and forth between Delphi and C# - but parameters won't work properly. The C# will receive all parameters as nulls and Delphi doesn't seem to be receiving response parameters properly. The final code step is to use a slightly customized THTTPRIO object that will allow for literal parameters. The trick to this part is to make sure that the option is applied AFTER the interface has been obtained; doing it before won't work. Here's the code from my example (just snippets).

Fix Step 4

var
  R: THTTPRIO;
  C: IVMProvisionCore;
begin
  R:= THTTPRIO.Create(NIL);
  C:= GetIVMProvisionCore(False, TheURL, R);
  R.Converter.Options:= R.Converter.Options + [soLiteralParams];

And now - my Delphi 2007 app can talk to the C#, stand-alone, non-IIS, WCF web service!

Jason Swager
A: 

Thanks a lot!!!

A: 

Thanks - this helped a lot. I had trouble with a couple more wrinkles. For me, issue #2 (SOAPAction) was all fouled up because the OperationName didn't match. The .Net group standardized on placing "In" at the end of the SOAPAction, but not the Operation.
So yadda.yadda.com/whatever/services/%operationName% really needs to be yadda.yadda.com/whatever/services/%operationName%In In this specific case.

It took me quite a while to spot that, but I finally noticed by testing in parallel with SoapUI, that it had different SOAPActions than the ones coming back in the error response. I fixed that, and it worked. But this was after struggling quite a while trying to figure out what should be in the DefaultSOAPAction in the first place. Again, SoapUI was helpful here.
So anyway, if you find that you get this error: "Action (whatever) cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher..." The first step is to populate the DefaultSOAPAction, and if problems persist, compare the one reported in the error against what really should be there.
HTH, Chris

Chris Thornton