When you publish a BizTalk schema or a BizTalk orchestration as a webservice, you may find you have left the warm comfort of BizTalk and now have to become an IIS and WCF expert.
MEX, WSDL, Endpoints
From what I have gleaned from the sites below, you really don’t need “MEX” endpoints. “MEX” stands for Metadata Exchange. However, they will return the WSDL to you with one call, instead of several.
MEX and WSDL are two different schemes to tell potential clients about the structure of your service.So we can choose to either make the service contracts public as “metadata exchance format” (MEX) or in the “web service description language” (WSDL) — the latter being accessible via HTTP(s). There’re 2 ways to expose metadata.One with MEX endpoint and one with
Above quoted from: Saurabh Somani’s blog – Http Get vs Mex End Point
One forum post said that “WSDL” is the “legacy method” and “MEX” is the “new improved version”. But he was corrected by a follow-up post, saying that WSDL is still used by many service platforms, and MEX and WSDL delivery the same output. (Ido’s blog above actually compares the results from the two.)
Mex is designed to support non-HTTP protocols. A client can add a reference in VS only if httpGetEnabled/httpsGetEnabled is enable or if you have define a mex endpoint in the configuration of your service. The best practice is to expose metadata on dev environnement but not on production. MEX are more configurable, while WSDL is more interoperable with older versions of clients and non-.net clients that work with WSDLs.
To disable MEX and expose your service via WSDL, then 1) do not specify a MEX endpoint, and 2) specify httpGetEnabled=”true”.
BizTalk and Error “Could not find a base address that matches scheme http for the endpoint with binding MetadataExchangeHttpBinding”
The MSDN forum posts weren’t coming up in Google, I only found them when I posted in the MSDN forum for BizTalk. So I decided to post them here to give them some “google love”. None of them actually helped me solve my issue, but when you are getting this error you probably need to read all of them to see which one fits your case.
My issue – WCF Published Orch – BizTalk could not find a base address that matches scheme http for the endpoint with binding wshttpbinding MetadataExchangeHttpBinding
Solution: Added port 80 to Bindings for website. Something in the WSDL/MEX needed http instead of https.
BizTalk – WCF error could not find a base address that matches scheme https for the endpoint with binding
Solution: referred to another WCF (Non-BizTalk) post WCF Security using custom username and password
BizTalk – could not find a base address that
matches scheme http for the endpoint with binding webhttpbinding
Solution: 1) Under bindings tag make sure you have set
<security mode="Transport" />
2) Also please try to use the mexHttpsBinding:
<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange"/>
3) Add base address
<baseAddresses> <add baseAddress=https://localhost:10201/Service /> </baseAddresses>
BizTalk could not find a base address that matches scheme http for the endpoint with binding wshttpbinding
Solution: This is working fine after i have changed my configuration file. i forgot to include binding configuration and changed mexHttpBinding to mexHttpsBinds and changed httpGetEnabled = false.
Solution for that issue: This is working fine after i have changed my configuration file. i forgot to include binding configuration and changed mexHttpBinding to mexHttpsBinds and changed httpGetEnabled = false.
BizTalk could not find a base address that matches scheme http for the endpoint with binding – Registered base address schemes are [https]
Solution: Just wondering whether you have configurd you application directory with HTTP protocol supports. Sometimes ppl tends to delete that and get the above exception. I have the following config for a test calcservice and it all works fine.
Moving to https = Could not find a base address that matches scheme
Solution: I’m not sure what was wrong but I simply took the certificate off and peeled the whole thing back to using basic http. I then carefully reapplied everything and it just worked. I think it was some sort of quirk or missed step in IIS.