WCF Part 4 : Make your service visible through metadata

Last time we saw how we could create an instance of our service by hosting it using some configuration in our app.config. We still need to have it exposed using metadata though. We’ll do this by adding an endpoint that exposed this, using our WCF ABC again. This endpoint is called a MEX endpoint, from Metadata EXchange.

For this we don’t have to create any code, just configuration again. Open the Service Configuration Editor again on our app.config. Open the folder “Advanced”, then “Service Behaviors” and choose to add a new service behavior. We’ll change the name NewBehavior to HelloServiceBehavior. Now click the Add button and select the ‘ServiceMetadata’ option.

Our added service behavior for the MEX endpoint.

Now we’ll configure our new behavior in and endpoint. Select your service again in the tree. This is something you’ll probably forget a lot in the future, but you’ll have to bind the just configured behavior to your service. You should be able to select it from the list in the BehaviorConfiguration property on your service.

Now let’s actually add our MEX endpoint. Select the “Endpoints” folder under our service and right-click it, then choose to add a new endpoint. Set the address to http://localhost:8080/HelloService/MEX/, select for binding the “mexHttpBinding” and for contract fill in “IMetadataExchange”. Now save, exit the configuration editor and you should have the following configuration.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior name="HelloServiceBehavior">
                    <serviceMetadata />
                </behavior>
            </serviceBehaviors>
        </behaviors>
        <services>
            <service behaviorConfiguration="HelloServiceBehavior" name="Classa.Wcf.Samples.Hello">
                <endpoint address="http://localhost:8080/HelloService/" binding="basicHttpBinding"
                    bindingConfiguration="" contract="Classa.Wcf.Samples.IHello" />
                <endpoint address="http://localhost:8080/HelloService/MEX/" binding="mexHttpBinding" bindingConfiguration=""
                    contract="IMetadataExchange" />
            </service>
        </services>
    </system.serviceModel>
</configuration>

Run your service with F5. You’ll notice no difference, but now you can create a proxy with the service util. Open the Visual Studio Command Prompt (in your start menu under Visual Studio 2005/Visual Studio Tools) and execute the following command:

svcutil.exe /o:client.cs /config:app.config http://localhost:8080/HelloService/MEX/

If you’re interested, take a look at the generated files. Especially the generated app.config, which should contain an ABC reference to your service.

[Go to the WCF series article index]

You may also like...

9 Responses

  1. You may be pleased to know that Microsoft will release a service factory for WCF services next month!!!

  2. I’m not sure I care… From what I’ve seen so far, the service factory isn’t my kind of thing.

    You made a post that at TechEd they had a service up and running in 10 minutes. I can do this by hand in under 30 seconds!

  3. Jean-Paul Smit says:

    What is the extra you get by adding an ‘mex’ endpoint?
    I noticed you can generate a client by just adding a behaviour and have the ‘httpgetenabled’ set to true.

    Can you tell a bit more about what the mex is for?

  4. The Metadata behavior will generate your WSDL and XSD. It kind of crawls over your contracts, looks at them and generates these xml documents.

    When you want to provide this through HTTP you must specifiy HttpGetEnabled. But when you use the service-util (svcutil.exe) you don’t need the http-get.

    In the old days (before the June 2006 Beta) the MEX endpoint was added automatically. I figure about 80% of the demo-code available on the internet, doesn’t comply anymore to the MEX endpoints you now have to add manually. 🙂

    Anyway, MEX endpoints are more than http-gets, you can also support https, tcp, etc. Where in the asmx days, you always had your WSDL via HTTP. You can also choose to NOT have a MEX endpoint and provide your customers with a WSDL and XSD’s of your own.

  5. Michael says:

    Okay, so this is all well and good. I take it the examples are done using a full version of Visual Studio? What do you do if you’re trying to walk through these examples and all you’ve got is Visual C# Express 2010?

  6. Dennis van der Stelt says:

    @Michael : As far as I know, should work exactly the same. The only difference is that you don’t have the team building stuff and some advanced remote debugging of assemblies in Express, plus no AddOn support. Should work exactly the same for everything else.

  7. erum says:

    can any one correct my service problem

    <!–
    The section enables configuration of the security authentication mode used by ASP.NET to identify an incoming user. –>

    <!–
    The section enables configuration of what to do if/when an unhandled error occurs during the execution of a request. Specifically, it enables developers to configure html error pages to be displayed in place of a error stack trace. –>

    my email address is [email protected]

  8. sam says:

    hi dennis,
    I have a problem! after following your steps the generated app.config file for service does not contain (service behaviorConfiguration=”HelloServiceBehavior” )
    and i add it by hand to app.config, where is my mistake?

  9. Tung says:

    I’ve created a service in which three bussiness endpoints are. I’ve also created a mex endpoint to describe them. But I want to show only two endpoints. So How can I do that? Thanks.

Click on a tab to select how you'd like to leave your comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.