Believe it or not, Mono has full ASP.NET 1.1, and a near-complete ASP.NET 2.0 class compatibility (check it out!). Not only that, there's two different ways of hosting a Mono/ASP.NET application, via xsp2 (for development) or with Apache 2 and mod_mono (for production). The only logical progression for a hacker such as myself, was to write a Mono-based Facebook application, and thus Weather# was born.
Fortunately the pervasiveness of Facebook client libraries is approaching the commonality of Twitter client libraries, mostly because it's a simple REST API, and it's cool. Since somebody already wrote the code, and weaseled it into the Mono Subversion repository (facebook-sharp) I decided to use it instead of rolling my mini API. The code was a bit old, and obtuse to deal with, so I simply incorporated all of the classes into my project, building everything into my web application. Using one of the many SOAP webservices available on xmethods.net, I used the wsdl.exe app to generate my SOAP client stubs (which are always subclasses of System.Web.Services.Protocols.SoapHttpClientProtocol), which left me with only about 150 lines of interface and basic glue code to bring these components together such that on page load:
- The user location information is fetched from Facebook
- A SOAP request to the weather web service is made per zip code or city
- The return data is parsed and fed into the page for display
The entire project was built in MonoDevelop which has pre-built ASP.NET templates which include customizable build, run and deploy settings for the MonoDevelop build system. When you click "Run" from inside MonoDevelop IDE, it will rebuld the solution, launch your project inside of xsp2 and then open up a new tab in Firefox to the web application. Building/Testing/Deploying is definitely the easiest part of the road to ASP.NET on Mono.
While the ASP.NET Visual Designer is not yet ready for prime time, it's only a minor set back in that you can't drag and drop your web interface together a la Visual Studio .NET, but you have to revert to how most of the web builds their interfaces, with templates and by hand. Given the sheer simplicity of the Weather# interface, this wasn't a major hurdle to overcome.
The only true problem with this near-perfect development setup is the actual public deployment, there are only a few hosts that provide mod_mono hosting as of yet. One of the most beneficial features of Mono however, is the full binary compatiblility with .NET, meaning you can develop your entire web application using the free and open source Mono tools, and then deploy your web application to an IIS ASP.NET server (which are very common in the hosting biz). If you have a colocated server, or a virtual private server, it's trivial to setup mod_mono on your Apache 2 web server with most of the mainstream Linux OSes and *bSD's. With ubuntu, in my case, there's only a few packages to install via Synaptic and then move the configuration over in the /etc/apache2/mods-enabled directory and make sure your configuration is correct. That said, if you're the proud owner of a colocated server it should be trivial to configure everything properly.
Facebook includes a couple key parameters in their calls into your page to present the user your application, such as the fb_sig_user and fb_sig_session_key, both of which you can pass into any Facebook client library to start to have your application querying the Facebook Platform. Weather# only makes this call once to users.getInfo to fetch the location information it needs. You can query for a lot more information if necessary, but for the purposes of this example, fetching the location was as basic as was necessary. The most complex part is setting up your Facebook applications settings in "My Applications", the Weather# information can be found here (opens in a new window). The most important information is in the screenshot, but if you'll note the callback URL settings. They are set to "iframe" for development purposes (and my desire not to open another port in the firewall to my workstation) and are hitting localhost port 8081, which is the local port I configured my MonoDevelop-deployment xsp2 settings to use. If you switch it over to FBML, you will either have to serve up FBML to the canvas page, or an <fb:iframe/>, but both require Facebook being able to contact your callback URL for proxying purposes.
Developing with ASP.NET on Mono is essentially no different than developing with ASP.NET on the stock Microsoft .NET assemblies with the key difference being...no Microsoft .NET assemblies, and no IIS. Meaning, that if you're comfortable with C# or Visual Basic, you can very quickly, and very cheaply develop ASP.NET-based web applications (or web services) and serve them from within your existing LAMP infrastructure. In my opinion, this is one of the best options out right now for current web development, right behind Python; the absolute power of the .NET class libraries is unparalleled, from web controls, to web services, to ADO.NET for data storage, the tools available to the overworked and underpaid developer are worth looking into if you're not already "in the know." mod_mono and xsp2 both run on Mac OS X, Linux, and FreeBSD, and are in the package systems across those platforms (MacPorts, APT, or Ports). MonoDevelop works on Linux and FreeBSD, you can get it working on Mac OS X but it's about as painful as a brazilian bikini wax (erm..so I'm told).
- Weather# screenshot
- Source: svn co svn://svn.geekisp.com/bleep/trunk/WeatherSharp
- Facebook Developers Site