I changed the name of the SchemeTest() method to SimpleTest() because the scheme test will be done on the POST request sending XML, not on a GET request.

Here is the new interface:

namespace WCFServiceWithScheme
{
    [ServiceContract]
    public interface ITestService
    {
        [OperationContract]
        [WebGet(UriTemplate = "SimpleTest?name={name}")]
        string SimpleTest(string name);

        [OperationContract]
        [WebInvoke(Method = "POST", UriTemplate = "SchemeTest",
           BodyStyle = WebMessageBodyStyle.Bare,
           RequestFormat = WebMessageFormat.Xml)]
        string SchemeTest(RequestObject theRequest);
    }
}

Here are the new public methods:

namespace WCFServiceWithScheme
{
    public class TestService : ITestService
    {
        public string SimpleTest(string name)
        {
            return "The name is " + name;
        }

        public string SchemeTest(RequestObject theRequest)
        {
            return "nothing interesting";
        }
    }
}

We have to create the simple object that will be POSTed in the request. I called it 'RequestObject'.
Notice we have included a namespace in the DataContract. This will also have to be sent in the request to the service.

namespace WCFServiceWithScheme
{
    [DataContract(Namespace = "http://WCFServiceWithScheme")]
    public class RequestObject
    {
        [DataMember]
        public string FirstName { get; set; }
        [DataMember]
        public string LastName { get; set; }
        [DataMember]
        public short Age
        {
            get { return age; }
            set { age = value; }
        }

        private short age = 0;
    }
}

The XML submitted for this object is here. Notice the namespace is included.

<?xml version="1.0" encoding="utf-8" ?>
<RequestObject xmlns="http://WCFServiceWithScheme">
     <Age>21</Age>
     <FirstName>Howard</FirstName>
     <LastName>Lumpy</LastName>
</RequestObject>

On a GET request, the relevant data is in the parameters. Here is how to read this data:

• Determine the request's mothod (GET or POST)
  You don't know what method is called or how it was called.
• Get the URITemplateMatchResults
• Get the operation name (method) that was called.
• Get the RequestUri
• Loop thru the Querry Parameters
• Loop thru the Bound Variables

NOTE: Any request to the service will run thru there. If you have 10 different GET and POST methods in your service, a request to any of them will go thru here before it goes to the called method.

public object AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel, System.ServiceModel.InstanceContext instanceContext)
{
    // Get the request message from the request
    HttpRequestMessageProperty requestMessage = request.Properties["httpRequest"] as HttpRequestMessageProperty;
    string method = string.Empty;
    if (requestMessage != null)
    {
        // The method will be GET or POST.
        method = requestMessage.Method;
    }

    // Get the UriTemplateMatchResults from the request.
    // Here you can see some of the fun things that are revealed.
    UriTemplateMatch results = internalCopy.Properties["UriTemplateMatchResults"] as UriTemplateMatch;
    if (results != null)
    {
        // Get the operation name from the request.
        // Here you can see what method was called in the Service.
        // Since we have only one method (SchemeTest), it should be this.
        // We can add a simple 'HelloWorld' method to see this value change.
        string operationName = string.Empty;
        if (results.RelativePathSegments.Count > 0)
            operationName = results.RelativePathSegments[results.RelativePathSegments.Count - 1];

        //
        string requestUri = results.RequestUri.ToString();

        // If the request method is GET, then you can play with the query parameters, uri template, and bound variables
        if (method == "GET")
        {

            // Loop thru the querry parameters
            NameValueCollection queryParameters = results.QueryParameters;
            foreach (var p in queryParameters)
            {
                Console.WriteLine(p);
            }

            // The Uri template is the same as in the Attribute of the interface: [WebGet(UriTemplate = "SchemeTest?name={name}")]
            string template = results.Template.ToString();

            // You can loop thru the key in the variables passed in.
            NameValueCollection boundVariables = results.BoundVariables;
            foreach (string key in boundVariables.AllKeys)
            {
                // Variable names are always in UPPER case. Don't know why.
                if (key == "NAME")
                    Console.WriteLine("This is the 'name' key");
            }
        }

       Object correlationState = new object();
       return correlationState;
}

When your web service is called, before the request reaches the main service method, the 'AfterReceiveRequest()' method is fired.
Here is where you can inspect the request.

Very important to know, you must make a copy of the message because reading the original message changes its State from 'created' to 'copied' and downstream processing won't work. Do this by creating a buffered copy.
NOTE: This applies mostly to getting the message body from a POST request.

public object AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel, System.ServiceModel.InstanceContext instanceContext)
{
    Console.WriteLine("Inside the ApplyClientBehavior");

    // Create a buffered copy of the request.
    // You can then use the internal copy to work with.
    MessageBuffer buffer = request.CreateBufferedCopy(Int32.MaxValue);
    request = buffer.CreateMessage();
    Message internalCopy = buffer.CreateMessage();
    buffer.Close();

    // Check the message state easily
    Console.WriteLine("State of message: " + internalCopy.State);

    Object correlationState = new object();
    return correlationState;
}

This example is based on the Simple Service example. I modified the Simple Service example and added the IDispatchMessageInspector.

The IDispatchMessageInspector gives you access to 2 events.
- AfterReceiveRequest() fires before you enter the web service method:
object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext) { return new Object; }
- BeforeSendReply() fires after you leave the web service method:
void BeforeSendReply(ref Message reply, object correlationState) { }

The object returned from the first method is the 'correlationSate' object of the 2nd method. If your custom validation fails in the first, you can return a 'correlationState' object that the 2nd method will receive automatically. This allows you to return 'Bad Request' or something like that.

There is nothing unusual about the Interface for the service as you can see in ITestService.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;

using System.ServiceModel.Web;

namespace WCFServiceWithScheme
{
    // NOTE: If you change the interface name "ITestService" here, you must also update the reference to "ITestService" in Web.config.

    [ServiceContract]
    public interface ITestService
    {
        [OperationContract]
        [WebGet(UriTemplate = "SchemeTest?name={name}")]
        string SchemeTest(string name);
    }
}

There is also nothing unusual about the class that inherits from the interface. TestService.svc.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;

namespace WCFServiceWithScheme
{
    public class TestService : ITestService
    {
        public string SchemeTest(string name)
        {
            return "The name is " + name;
        }
    }
}

The differences begin to show in the Web.config.
You will see the 'behaviorExtensions' tag and the additional addition to the 'endpointBehaviors'.
The name for the 'behaviorExtensions' is the new behavior in the 'endpointBehavior'.
The behaviorExtensions' TYPE is the name of the BehaviorExtensionElement class followed by the namespace.

The system.serviceModel in the Web.confi:

  <system.serviceModel>

    <!-- Required for IDispatchMessageInspector -->
    <extensions>
      <behaviorExtensions>
        <add name="restHttpBehavior" type="WCFServiceWithScheme.MyBehaviorExtensionElement, WCFServiceWithScheme, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
      </behaviorExtensions>
    </extensions>

    <bindings>
      <!-- Minimum for WebHttp -->
      <webHttpBinding>
        <binding name="WCFServiceWithScheme.MyDefaultBinding"/>
      </webHttpBinding>
    </bindings>

    <behaviors>

      <!-- serviceBehaviors -->
      <serviceBehaviors>
        <behavior name="WCFServiceWithScheme.MyServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>

      <!-- endpointBehaviors -->
      <endpointBehaviors>
        <behavior name="WCFServiceWithScheme.MyWebBehavior">
          <webHttp/>
          <restHttpBehavior/>
        </behavior>
      </endpointBehaviors>

    </behaviors>

    <services>

      <!-- Minimum for WebHttp -->
      <service behaviorConfiguration="WCFServiceWithScheme.MyServiceBehavior" name="WCFServiceWithScheme.TestService">

        <!-- Minimum for WebHttp -->
        <endpoint address="web" behaviorConfiguration="WCFServiceWithScheme.MyWebBehavior" binding="webHttpBinding" contract="WCFServiceWithScheme.ITestService" bindingConfiguration="WCFServiceWithScheme.MyDefaultBinding">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>

      </service>

    </services>
  </system.serviceModel>

There are 2 new classes that you must create:
* A MessageInspector class that inherits from IDispatchMessageInspector
* A BehaviorExtensionElement class that inherits from BehaviorExtensionElement and IEndpointBehavior.

The MessageInspector class contains the AfterReceiveRequest and BeforeSendReply methods.
Place break points in these methods and you can see the order in which they are fired.

The MyMessageInspector.cs class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ServiceModel.Dispatcher;

namespace WCFServiceWithScheme
{
    public class MyMessageInspector : IDispatchMessageInspector
    {

        #region IDispatchMessageInspector Members

        public object AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel, System.ServiceModel.InstanceContext instanceContext)
        {
            Console.WriteLine("Inside the ApplyClientBehavior");
            // Good idea to return error class stuff to let you know if anything happened in here
            Object correlationState = new object();
            return correlationState;
        }

        public void BeforeSendReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
        {
            // !!!!!!!!! correlationState comes from the AfterReceiveRequest method !!!!!!!!!!!!!
            // If the AfterReceiveRequest method determines it is a bad request, this is where you return, 'Bad Request'
            Console.WriteLine("Inside the ApplyClientBehavior");
        }

        #endregion
    }
}

The BehaviorExtensionElement class contains several methods. The most important one is 'ApplyDispatchBehavior(). This is where you add your message inspector.

The Validate() is fired only during initialization of the service and before ApplyDispatchBehavior().
To test this when running locally, do an IISreset, place a break point in the Validate() method and the other methods, and hit F5 to start debugging.

MyBehaviorExtensionElement.cs

using System;
using System.ServiceModel.Configuration;
using System.ServiceModel.Description;

namespace WCFServiceWithScheme
{
    public class MyBehaviorExtensionElement : BehaviorExtensionElement, IEndpointBehavior
    {
        #region BehaviorExtensionElement
        public override Type BehaviorType
        {
            get { return typeof(MyBehaviorExtensionElement); }
        }

        protected override object CreateBehavior()
        {
            return new MyBehaviorExtensionElement();
        }
        #endregion

        #region IEndpointBehavior Members

        public void AddBindingParameters(ServiceEndpoint endpoint, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
        {
            Console.WriteLine("Inside the AddBindingParameters");
        }

        public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)
        {
            Console.WriteLine("Inside the ApplyClientBehavior");
        }

        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
        {
            Console.WriteLine("Adding custom message inspector...");
            endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new MyMessageInspector());
        }

        public void Validate(ServiceEndpoint endpoint)
        {
            Console.WriteLine("Inside the Validate");
        }

        #endregion
    }
}

NOTE: This is different than the Secure WCF REST webservice I posted earlier. The previous one uses the WCF REST Starter Kit and has a very simple Web.config.

This series covers:

• Creating a Simple Service based on REST
• Expand the simple service with IDispatchMessageInspector
• Read the GET request parameters in the AfterReceiveRequest() method
• Add a POST method to the service
• How and why you should use 'CreateBufferedCopy' to clone the request
• Read the message body in a POST request
• Loading and using the scheme
• Dynamically expanding the UriTemplate on a Get request
• How to optionally embed the XSD file in the assembly

My goals were:
* use WCF/REST
* Use a Schema to validate the incoming XML request
* Extend the deserialize method turn prohibit DTDs and to disable external entities
* Filter IPs based on a list in the Config file
* Use the newer WebServiceHost2 from the WCF REST Starter Kit

Problems I had:
* I tried extending IDispatchMessageInspector and IClientMessageInspector to add schema validation. This worked great on WS Services (wsHttpBinding), but I could not get it to work on WebServices (webHttpBinding). I could not find any exampels of working solution on the net on how to do this with web services. (here is the blog post on what I did come up with). I abandoned this approach.

* Schema validation is done on the xml before it is derialized or when it is deserialized to an object. Because I could not access the deserialization before accepting the incoming xml request, I was forced to have the incoming object type 'XElement' rather than the destination object.

My solution:
* I used the new WCF REST Starter Kit. This reduces the confit file to almost nothing. The endpoints are set automatically. All adjustments can be done thru attributes on the service method itself.

Here is my config file:

<?xml version="1.0"?>
<configuration>
  <appSettings>
     ...
  </appSettings>

  <system.web>
		<compilation debug="true"/>
  </system.web>

  <system.serviceModel>
		<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
  </system.serviceModel>
</configuration>

My Service:

// The following line sets the default namespace for DataContract serialized typed to be ""
[assembly: ContractNamespace("", ClrNamespace = "ThisIsMyService")]

namespace ThisIsMyService
{
    // TODO: Please set IncludeExceptionDetailInFaults to false in production environments
    [ServiceBehavior(IncludeExceptionDetailInFaults = true), AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed), ServiceContract]
    public partial class Service
    {
        [WebHelp(Comment = "This is my service")]
        [WebInvoke(UriTemplate = "MyService")]
        [OperationContract]
        public XElement MyService(XElement requestXml)
        {
            // Schema validation and deserialization are both done at the same time.
            // If there is a problem, null is returned and an exception is thrown with a HTTPStatusCode of Bad Request.
            var validatedObject = Helper.XmlToObject(requestXml, typeof(RequestObject),
                ConfigurationManager.AppSettings["SchemaPath"].ToString(),
                ConfigurationManager.AppSettings["SchemaNamespace"].ToString());

            // I do all the process and other work in the helper class to keep this clean.
            if (validatedObject is RequestObject)
                return new Helper().DoStuff((RequestObject)validatedObject);

            // If there is problem validating the incoming request XML, then the validated object will be null
            // Error validating request - return nothing
            return new XElement("root");
        }
    }
}

My service is very basic. All the logic is done in the helper class.

My helper class contains the static validation XMLtoObject method and the methods for doing the work of the service.

When you deserialize XML to an object, you can add a schema that will be used to check the XML.
What you don't easily find in the documentation, is the fact that the Schema must be read and validated before it can be added to the reader that reads and deserializes the incoming xml request.

public class EngineServiceHelper
{
    /// <summary>
    /// A schema is an XML file like all the rest.
    /// It also must be loaded and deserialized.
    /// To use a schema, it must be placed in a XmlSchemaSet.
    /// </summary>
    /// <param name="xml"></param>
    /// <param name="DestinationType"></param>
    /// <param name="schemaPath"></param>
    /// <param name="xmlNamespace"></param>
    /// <returns></returns>
    public static object XmlToObject(XElement xml, Type DestinationType, string schemaPath, string xmlNamespace)
    {
        ErrorMessage = string.Empty;
        ErrorsCount = 0;

        XmlSchemaSet schemaSet = new XmlSchemaSet();
        schemaSet.ValidationEventHandler += new ValidationEventHandler(settings_ValidationEventHandler);
        schemaSet.Add(xmlNamespace, schemaPath);

        if (schemaSet.Count > 0)
        {
            try
            {
                // Set the setting for reading the Schema file
                XmlReaderSettings schemaSettings = new XmlReaderSettings();
                schemaSettings.ValidationType = ValidationType.Schema;
                schemaSettings.Schemas.Add(schemaSet);
                // To make the service more secure and prevent XML Bombs and such, disable DTDs
                xmlRequestSettings.ProhibitDtd = true;
                // Limit the size of the elements - 1024 = 1Kb
                schemaSettings.MaxCharactersFromEntities = 1024;
                // Adding the validation event handler prevents validation errors from throwing an exception.
                // We want to control when and how an exception is thrown.
                schemaSettings.ValidationEventHandler += new ValidationEventHandler(settings_ValidationEventHandler);
                // create the reader for reading the schema
                XmlReader schemaReader = XmlReader.Create(xml.CreateReader(), schemaSettings);

                // Set the settings for reading the incoming XML request
                XmlReaderSettings xmlRequestSettings = new XmlReaderSettings();
                // To make the service more secure and prevent XML Bombs and such, disable DTDs
                xmlRequestSettings.ProhibitDtd = true;
                // Limit the size of the elements - 1024 = 1Kb
                schemaSettings.MaxCharactersFromEntities = 1024;
                // Create the reader for reading the XML request.
                XmlReader xmlReader = XmlReader.Create(schemaReader, xmlRequestSettings);

                // Deserialize the XML to an object
                XmlSerializer serializer = new XmlSerializer(DestinationType, xmlNamespace);
                object returnObject = serializer.Deserialize(xmlReader);

                // If there are errors, throw an exception
                if (ErrorsCount > 0)
                    throw new Exception(ErrorMessage);

                // If ther are no problems, return the deserialized object
                return returnObject;
            }
            catch (Exception ex)
            {
                // Using the WebProtocolException in the WCF REST Starter Kit, you can throw
                // and exception and choose the HTTPStatusCode that will be displayed to the end user.
                throw new WebProtocolException(HttpStatusCode.BadRequest, "Your XML is invalid: " + ex.Message, null);
            }
        }
        return null;
    }

    /// <summary>
    /// Check the error severity and create the error message.
    /// Increment the error counter.
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    public static void settings_ValidationEventHandler(object sender, ValidationEventArgs e)
    {
        if (e.Severity == XmlSeverityType.Error)
        {
            ErrorMessage = "ERROR: " + ErrorMessage + e.Message + "\r\n";
            ErrorsCount++;
        }
        else
        {
            ErrorMessage = "WARNING: " + ErrorMessage + e.Message + "\r\n";
            ErrorsCount++;
        }
    }
}

The validation event handler allows you to catch the validation errors and handle them yourself.
I am checking the error severity and returning a message that reflects it.

These attributes define how the object will be serialized. The serialization is VERY important.

If your serialization is not correct, you will get unpredictable behavior. Some of the problems I experienced was values not being passed into the object from the xml string, exceptions thrown when the order is not correct or incorrect default values entered.

The most important items I found were
* order (alphabetical)
* root element attributes ()
* zero default for int values ('0')
* represent all possible values, even if they are not used ('' vs '' does not make a difference until it is an int/numeric/etc.)

Some of these are no-brainers. But the order? Why should the order matter when the DataMember attributes don't specify an order? It does and there seems to be no reason why.

Here is my object:

[DataContract]
public sealed class InputXMLObject
{
    // Required
    [DataMember(IsRequired = true)]
    public string Language { get; set; }
    [DataMember(IsRequired = true)]
    public string Name { get; set; }
    [DataMember(IsRequired = true)]
    public int MyId { get; set; }

    // Optional
    [DataMember(IsRequired = false, EmitDefaultValue = true)]
    public string SomeThing { get; set; }
    [DataMember(IsRequired = false, EmitDefaultValue = true)]
    public string SomethingElse { get; set; }
    [DataMember(IsRequired = false, EmitDefaultValue = true)]
    public string Timestamp { get; set; }
}

I serialized it with this nifty little method. I like it because it is generic. The most important part about it that it uses System.Runtime.Serialization.DataContractSerializer. I found this method on Peter Ritchie's blog.

public static string ContractObjectToXml<T>(T obj)
{
    DataContractSerializer dataContractSerializer = new DataContractSerializer(obj.GetType());
    String text;
    using (MemoryStream memoryStream = new MemoryStream())
    {
        dataContractSerializer.WriteObject(memoryStream, obj);
        byte[] data = new byte[memoryStream.Length];
        Array.Copy(memoryStream.GetBuffer(), data, data.Length);
        text = Encoding.UTF8.GetString(data);
    }
    return text;
}

After serialization, the object looked like this:

<InputXMLObject2 xmlns="http://schemas.datacontract.org/2004/07/MyService" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><Language>UK</Language><MyId>5</MyId><Name>Billy</Name><SomeThing i:nil="true"/><SomethingElse i:nil="true"/><Timestamp i:nil="true"/></InputXMLObject2>

I made it a bit more simple (the ' i:nil="true"' is not necessary):

<InputXMLObject xmlns="http://schemas.datacontract.org/2004/07/EMyService" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
	<Language>UK</Language>
	<MyId>5</MyId>
	<Name>Billy</Name>
	<SomeThing></SomeThing>
	<SomethingElse></SomethingElse>
	<Timestamp></Timestamp>
</InputXMLObject>

My interface:

[ServiceContract]
public interface IEngineService
{
    [OperationContract]
    string MyServiceMethod(InputXMLObject inputXMLObject);
}

The class:

public class EngineService : IEngineService
{
	public string MyServiceMethod(InputXMLObject inputXMLObject)
	{
           // do something
	}
}

First the interface for the service (ITestService.sc).
The interface has the 'ServiceContract' interface.
The service method has the 'OperationContract'.
You will notice the attribute 'WebGet()'. This specifies the service will be accessed via GET. (This uses the class System.ServiceModel.Web - it must be added as a reference as well. Confirm also that System.ServiceModel has also been added and is incuded in the 'Using' list).

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
using System.ServiceModel.Web;

namespace WCFService
{
    [ServiceContract]
    public interface ITestService
    {
        [OperationContract]
        [WebGet()]
        string Hello();
    }
}

Then the actual service itself (TestService.cs):

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;

namespace WCFService
{
    public class TestService : ITestService
    {
        public string Hello()
        {
            return "Hello world";
        }
    }
}

The file TestService.svc contains only placholder info:

<%@ ServiceHost Language="C#" Debug="true" Service="TestService" CodeBehind="~/App_Code/TestService.cs" %>

That was the easy part.
Now for the Web.config file.
All additions go under ''

The 4 additions are:
* binding
* service behavior
* endpoint behaviors
* endpoint

Our service uses 'webHttpBinding' service. Other binding types are 'wsHttpBinding' and 'mexHttpBinding' (not covered here... yet...)

The web.config settings

   <system.serviceModel>

    <bindings>
      <!-- Minimum for WebHttp -->
      <webHttpBinding>
        <binding name="WCFService.MyDefaultBinding"/>
      </webHttpBinding>
    </bindings>

    <behaviors>

      <!-- serviceBehaviors -->
      <serviceBehaviors>
        <behavior name="WCFService.MyServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>

      <!-- endpointBehaviors -->
      <endpointBehaviors>
        <behavior name="WCFService.MyWebBehavior">
          <webHttp/>
        </behavior>
      </endpointBehaviors>

    </behaviors>

    <services>

      <!-- Minimum for WebHttp -->
      <service behaviorConfiguration="WCFService.MyServiceBehavior" name="WCFService.TestService">

        <!-- Minimum for WebHttp -->
        <endpoint address="web" behaviorConfiguration="WCFService.MyWebBehavior" binding="webHttpBinding" contract="WCFService.ITestService" bindingConfiguration="WCFService.MyDefaultBinding">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>

      </service>

    </services>
  </system.serviceModel>

How do I call it?

This service is set up to be called via GET, so it is easy. (your localhost port may be different)

http://localhost:3041/SandboxWebsite/TestService.svc/Web/Hello

This returns:

Hello world

To call this in code, it is almost as easy.
Create a HTTPWebRequest. Pass in the URL. Specify the Method as GET. Get the response stream. Read the respons stream to the end and you have it.

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://localhost:3041/SandboxWebsite/TestService.svc/Web/Hello");
request.Method = "GET";
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
Stream stream = response.GetResponseStream();
StreamReader reader = new StreamReader(stream);
string s = reader.ReadToEnd();

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

Microsoft screwed up again. The temporary asp.net files are not being overwritten by newer version when necessary. While working with WCF services, I doscovered at least 30% of the time I had to manually delete the folder associated with my project.

However, do delete that temporary folder, I had to close Visual Studio. F@*K Microsoft! You all should know how long VS takes to close and open. Not nice.

Here is the error message that I have learned to hate (on my local Dutch langauge computer):

Kan bestand of assembly App_Web_pjcv_bjk, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null of een van de afhankelijkheden hiervan niet laden. Het systeem kan het opgegeven bestand niet vinden.