Generate c# classes from wsdl [closed]

Question

I want generate C# classes from wsdl url in ASP.NET Core 2.1.

WSDL url is:https://airarabia.isaaviations.com/webservices/services/AAResWebServices?wsdl

I used "Microsoft WCF Web Service Reference Provider" tool to generate C# class and got following error:

Error: No code was generated. If you were trying to generate a client, this could be because the metadata documents did not contain any valid contracts or services or because all contracts/services were discovered to exist in /reference assemblies. Verify that you passed all the metadata documents to the tool. Done.

Any solution will be appreciate.

Answer 1

Short answer

Open a development command prompt and run to generate the proxy classes:

svcutil http://airarabia.isaaviations.com/webservices/services/AAResWebServices?wsdl

Notice that I used http instead of https. The server's certificate causes problems with svcutil. Copy the classes into your project folder.

Add System.ServiceModel.Primitives from NuGet to the project's dependencies. Since ASP.NET Core doesn't use web.config files, you may have to create the bindings yourself when creating the proxy class, eg :

var binding = new BasicHttpsBinding(BasicHttpsSecurityMode.Transport);
var address = new EndpointAddress("http://airarabia.isaaviations.com/webservices/services/AAResWebServices");
var client = new AAResWebServicesClient((Binding)binding, address);

In the bindings, BasicHttpsBinding is used since no airline will accept unencrypted connections. Sabre requires TLS 1.2 or greater.

Explanation

Airlines and GDSs aren't great at following web interoperability standards. They are big enough that if there are any changes, it's the travel agent that has to accomodate them. Once they specify their standard, they don't care to change it either.

The OTA standard and Sabre's implementation for example were created in 2003 using ebXML, an alternative proposal to SOAP that didn't become a standard. Then they used ebXML over SOAP using mechanisms that didn't become part of the later SOAP standards. When the WS-* standards were created to fix the mess and ensure interoperability, they didn't even bother.

The WSDL you provided is similar to Sabre's. It uses some of OTA's operations like OTA_PING and adds custom ones. Fortunately, it doesn't include any tool-breakers like anonymous inner types.

You could use wsdl.exe to create an ASMX proxy, using the pre-2008 .NET stack. This hasn't been ported to .NET Core as far as I know though. Maybe it's part of the Windows Compatibility pack. After all, it is non-compliant and deprecated 10 years ago. ASMX hasn't had any significant upgrades in ages either. I have run into concurrency issues with deserializers in the past, when using ASXM services eg with Amadeus.

And then, there are those that won't even respect their own XSDs, eg Farelogix. They may return out-of-range values for enumerations and say "well, the XSD is for information purposes only". The wsdl file is clearly marked not for production use

There's no generic solution unfortunately. Here are some options:

• wsdl.exe and ASMX are out of the question if you want to use .NET Core. You'll have to switch to the Full framework if you have to use them.
• Create WCF individual proxies for each service. The size of the files is a lot smaller and you avoid clashes between types like Airport that are used by multiple services with slight variations or even incompatibilities.
• Use Fiddler or another tool to capture the requests and responses. Use these as templates to create plain HTTP GET requests. It's a dirty solution but could prove quicker and ever more reliable if you can't trust the provider's WSDL and XSDs

WARNING

Making the call doesn't mean that you can communicate with the provider. One of the main problems with ebXML over SOAP is that the body is OK but the headers, including those used for authentication are all wrong. This means that one has to create the authentication element

Another issue is that authentication fields are often misused eg using authentication headers we'd consider session tokens. GDSs still use mainframes and those session tokens often map to actual terminal sessions.

This means that one has to create authentication headers manually instead of relying on WCF to generate them. It also means that transactions are stateful - one has to keep track of which session was used for that reservation in order to book it, make sure all previous transactions are complete before starting a new one etc.

Answer 2

Download your WSDL files to local. Then, run the following command:

wsdl.exe /verbose /namespace:Air /out:D:\t\ar /protocol:SOAP /language:CS C:\path\to\wsdl\AAResWebServices_1.wsdl

Change namespace to a namespace of your choice.

WSDL.exe is part of your Windows SDK:

C:\Program Files (x86)\Microsoft SDKs\Windows

Mine was in C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin

This generated the classes without any issues. I tested this solution.