Conditional method attributes

Sometimes I like to include some code which will only run when complied in Debug config. This is simple enough, just add some preprocessor commands like so:

#if DEBUG
  //Do some debug-only stuff here.
#endif

However this always looks a bit ugly to me. A much tidier way of achieving the same is to use conditional method attribute like so:

[Conditional("DEBUG")]
private void DoSomething()
{   
  //Do some debug-only stuff here.
}

The only catch with this is that the method must return void. This is necessary to allow it to be included/excluded depending on the compilation config used. It can be worked around by using reference parameters on the method itself.

Anyway, here’s a photo of a skiing penguin.

Skiing Penguin

RESTful WCF services without .svc file and with very little configuration

WCF is, on the whole, pretty neat. It’s a doddle to decorate methods with UriTemplates and specify DataMembers. Building the actual meat of a web service is made very easy by the wealth of functionality available in WCF4, and this is the bit I usually happily chip together whenever I need to write a RESTful web service.

Then I get to the part where I have to add the service’s endpoint to web.config. It’s usually been several months since I last did it. I look it up on google, but the results don’t quite seem to apply to me. I open up an old project where I last did this ridiculous dance, but evidently I’m missing something because the damned thing still won’t work. The problem is most likely a subtly mis-set attribute. Or may web.config is just a monster which will eat us all.

With that in mind, I was recently delighted to find this blog post by Steve Michelotti. It’s a little old, but the knowledge within was new to me, so it may be new to you too.

In a nutshell, it leverages the WebServiceHostFactory class to allow a ServiceRoute to your WCF service to be defined. The advantages of this are two-fold:

  • No service-specific entries are needed in web.config
  • The WCF service can be defined in a plain C# class rather than a .svc file.

Steve covers this in much more detail in his blog post, so what follows is a quick summary of the steps required to get a service up and running:

  • Define your service in a C# class (implementing an interface is recommended but not required).
  • Decorate your class with
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

    This is required for the service to operate over HTTP.

  • A teensy bit of web.config tweaking is required. This is the other half of the configuration above.
    <system.serviceModel>
      <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
    </system.serviceModel>
  • Add a reference to System.ServiceModel.Activation. This is not to be confused with System.ServiceModel.Activision.
  • To add the ServiceRoute, add a line similar to the one below to Application_Start in Global.asax.cs:
    RouteTable.Routes.Add(new ServiceRoute("Services", new WebServiceHostFactory(), typeof(Your_Service_Class)));

    Where Your_Service_Class is the name of the class you previously wrote for your service. Leaving the first parameter of ServiceRoute blank results in all requests to the service being relative to the site route. Services in the example above is the route prefix of your service url. You can leave it blank, but I prefer to specify a path to keep my services tidily organised.  You should decorate your service methods with a suitable UriTemplate, eg

    [WebGet(UriTemplate = "MyService", ResponseFormat = WebMessageFormat.Json)]

    In the above case the service can be called via a browser on http://my_hostname/services/myservice

That’s it! I can now get on with the meaty business of writing code instead of wrestling with the beast that is web.config.

In the meantime, here are some goats in a tree.

Goats in a tree

Things which have emerged from my radiator

The previous tenants of my flat had a couple of children. This is of little consequence, except a month or so after moving in, I noticed something poking out from the bottom of the living room radiator:

I was a little surprised at first. Upon removing it completely it was revealed to a brightly-coloured fireman. Maybe there’s a similarly brightly-coloured fire engine in there too, I briefly wondered. Then I thought of something better to do, like check FaceBook.

I thought no more of the matter, although for some reason I couldn’t bring myself to throw the fireman away. However a few months ago the radiator yielded another gift:

This time it was a wooden number 2. It was painted green and had two small cows on it, presumably as part of a farmyard-themed set of numbers. I put it under the coffee table with the astronaut, but otherwise forgot about it, until last week, when the business end of a teaspoon poked out from the bottom of the radiator. This one took a little persuading to remove it from said radiator:

I put it with the other three items which have so far emerged. I wonder what, if anything is still in there, waiting for the hot/cold expansion/contraction cycle to pass it through the radiator’s vanes? I could get a stick and actively clean the thing out but this way is more fun. Should anything else I appear I’ll be sure to update this post. Anything less would be a dereliction of duty.