Professional Software Programming

I have recently started playing with the Facebook platform. The more familiar I become with developing for the Facebook platform, the more excited I get.

With the release of the by Clarity Consulting, Facebook development for .NET programmers has become very comfortable. I've been developing for the Microsoft .NET platform for several years and it was nice to learn that I could leverage this knowledge and experience when developing for Facebook.

It must be noted that I was able to get the IFRAME version of the Facebook application working immediately. However, I had been struggling exactly a day to get the FBML version of my "Hello World" Facebook application working.

To help fellow programmers, I have created a very simple Facebook application. The Visual Studio 2005 project can be downloaded from here: .

My application is located at: and a screen-shot of it is shown below. As you can see, for now the application doesn't do much. It just greets a Facebook user.



The screen-shots below show exact settings of the application in the Facebook application settings. Important changes are given in red circles and I have added some comments in red color as well.

Base Options



Installation Options



Integration Points



In order to get your ASP.NET based Facebook application working, obviously you will need an ASP.NET hosting.

The only problem that I see now is debugging the application. However, I have solved this problem. Not a very elegant solution, but gets the job done. More about it will be addressed in the next post.

So, stay tuned and don't forget to subscribe to my RSS feed.

If you have been working with ASP.NET web services, you might have noticed that on your local or development server, the web service exposes its methods via several ways (HTTP SOAP, HTTP Get, HTTP Post). Moreover, for those methods that accept parameters, the page displays HTTP Post form, which allows you to quickly test the web service.

However, when you deploy the web service, the only available methods for calling it is HTTP Soap. What if you need to allow HTTP Get and Post calls?

It turns out to be quite easy. Moreover, you can enable/disable protocols for a whole machine or for specific webservices. However, please keep in mind that enabling GET and POST protocols adds security risks. At least that's what Microsoft says. Technically, I don't think there is a considerable risk associated with enabling Post calls. Anyway, if you don't really need POST calls, then it's better to keep it disabled.

So, how do we do that anyway? Glad you asked. Look at the configurations below.

To enable HTTP GET and HTTP POST protocols for the whole machine:

Open the Machine.config file in a text editor. This file as rule lives in the \Config subdirectory of the installation root.

Add the following configuration between and tags.

<webServices>
    <protocols>
         <add name="HttpSoap"/>
         <add name="HttpPost"/>
         <add name="HttpGet"/>
      <add name="Documentation"/>
      <add name="HttpPostLocalhost"/>
    </protocols>
</webServices>

Save Machine.config.

This configuration change takes effect on the next request to a Web service hosted on that machine.


To enable support for a protocol for an individual Web application:

Open the Web.config file in the root directory of the Web application in a text editor.

Add the following configuration between and tags.

<webServices>
    <protocols>
         <add name="HttpSoap"/>
         <add name="HttpPost"/>
         <add name="HttpGet"/>
      <add name="Documentation"/>
      <add name="HttpPostLocalhost"/>
    </protocols>
</webServices>

Save Web.config.

This configuration change takes effect on the next request to a Web service hosted by the Web application.