WCF base address not found

My service can work with normal WCF calls, but to expose metadata (the wsdl file) I have to change configuration in such a way the normal WCF host fails.

I've spend countless hours on google trying to solve this, big problem there is that hosting a service inside a website is never discussed (yes this is different).

requirements:

• Runs in an existing web site
• Use sessions
• Operable with Java, and as much .net versions as possible.
• Expose metadata (wsdl will be enough)

edits:

• IIS cannot be used
• I'm using .NET 4 and WCF 4.

In this configuration the metadata can be reached (through the wsdl file) but when trying to host the normal wcf endpoints I get and InvalidOperationException:

Could not find a base address that matches scheme http for the endpoint with binding WSHttpBinding. Registered base address schemes are [].

So the base address is ignored.

But when I supply full addresses to the endpoints (simply copy the base address in front of the current address) the normal WCF calls work fine, but when trying to access metadata I get the following error: No protocol binding matches the given address 'http://localhost:8080/Functionality'.

Protocol bindings are configured at the Site level in IIS or WAS configuration.

Here is the web.config serviceModel section, I made a small test web site just for testing this, but it would be to much to post all of it here, if you send me a pm though I will e-mail it to you.

 <system.serviceModel>
  <services>
   <service behaviorConfiguration="metadataSupport" name="MyStuff.TestWithMetadata">
    <endpoint address="Functionality" binding="wsHttpBinding" name="FunctionalityBinding"
     contract="MyStuff.ITestWithMetadata" />
    <host>
     <baseAddresses>
      <add baseAddress="http://localhost:8080/" />
     </baseAddresses>
    </host>
   </service>
  </services>
  <behaviors>
   <endpointBehaviors>
    <behavior name="metadataSupport">
     <webHttp />
    </behavior>
   </endpointBehaviors>
   <serviceBehaviors>
    <behavior name="metadataSupport">
     <!--Navigate with browser to httpGetUrl for the wsdl file-->
     <serviceMetadata httpGetEnabled="true" httpGetUrl="Metadata" />
     <serviceDebug includeExceptionDetailInFaults="false" />
    </behavior>
   </serviceBehaviors>
  </behaviors>
  <serviceHostingEnviron开发者_运维知识库ment multipleSiteBindingsEnabled="false">
   <serviceActivations>
    <add relativeAddress="TestWithMetadata.svc" service="MyStuff.TestWithMetadata" />
   </serviceActivations>
  </serviceHostingEnvironment>
 </system.serviceModel>

If anyone has any ideas on how to solve this, please help out.

When you host your service in IIS (which I assume from your requirement "Runs in an existing web site"), then your base address in the config is moot - it will not be used at all.

When hosting in IIS, your service address is determined by:

• your server name
• possibly a port number
• the virtual directory (and possibly subdirectories thereof) where the *.svc file lives
• the *.svc file itself (including extension)

So it might be something like:

http://MyServer:7777/ExistingWebApp/TestWithMetadata.svc

or whatever it is that you have in your case.

You seem to be using .NET 4 and WCF 4 (never mentioned that.....) and in that case, you could skip the *.svc file altogether by adapting your config entry:

<serviceHostingEnvironment multipleSiteBindingsEnabled="false">
    <serviceActivations>
        <add relativeAddress="MyService" service="MyStuff.TestWithMetadata" />
    </serviceActivations>
</serviceHostingEnvironment>

In this case, the value of relativeAddress= becomes the service address (within the virtual directory this web.config lives in) - so your service address would be something like:

http://MyServer:7777/ExistingWebApp/MyService

No need for a *.svc file at all in this situation.

Turned out I should use httpGetUrl link to get the metadata, instead of the .svc file, with that the base address can be ignored.

I also moved this test stuff to the actual web site and got tons of problems with zero endpoints being loaded. That was caused by the service reference in serviceActivations not set to the full service name (needs to have namespace included).

I accepted marc's answer because he did help me along and to prevent this question from popping up in unanswered.