WWSAPI等效于C＃/。net <serviceCertificate> 在App.config中

Question

We're building a C++/WWSAPI client to connect with a third-party C#/.net server. We have a sample C#/.net client that works with the server. It has this in it's App.config (client.exe.config):

<behaviors>
  <endpointBehaviors>
    <behavior name="TheirBehavior">
      <clientCredentials>
        <serviceCertificate>
          <defaultCertificate findValue="crypt.theirdomain.com" storeLocation="LocalMachine" storeName="Root" x509FindType="FindBySubjectName"/>
        </serviceCertificate>
      </clientCredentials>
    </behavior>
  </endpointBehaviors>
</behaviors>
<client>
  <endpoint address="https://zzz.theirdomain.com/TheirService.svc"
    binding="customBinding" bindingConfiguration="TheirServiceBinding" behaviorConfiguration="TheirBehavior"
    contract="ProdWS.ITheirService" name="TheirServiceBinding">
    <identity>
      <dns value="crypt.theirdomain.com"/>
    </identity>
  </endpoint>
</client>

We also have a certificate, which we're loading properly (otherwise we get There was an error when trying to find certificate '...'; Cannot find object or property. before the call.)

How do we enable this in WWSAPI? Is there any reference that will show mappings between all .net configuration settings and the corresponding WWSAPI configuration?

The following configuration (set in WS_SECURITY_BINDING ) gives Invalid certificate credential specification in security binding. :

WS_SSL_TRANSPORT_SECURITY_BINDING sslBind{};
sslBind.binding.bindingType = WS_SSL_TRANSPORT_SECURITY_BINDING_TYPE;
sslBind.localCertCredential = &certCred.credential;

Is this on the right track?

Answer 1

We abandoned this approach. But to even get this far, we started using the free version of Visual Studio 2015 and ported our code and libraries to MSVC.

To make it work, we created a C# .dll project and added their .wsdl/.xsd files as a "Service Reference", then added that project as a Reference to our C++ one. Fraught with difficulties, including having to hack .NET v4.5 into the .vcxproj by hand, and having to enable /clr and do a mysterious patch to a lib because of it. But got it working.

Our vendor's claim of "interoperability" was baloney. Only C#, Visual Studio 2015, just exactly like they're using, then bridge that to your own.

Also, the Library.dll.config file needs to be renamed to the executable's Executable.exe.config, or .NET won't find it.