Bloomberg connectivity is a riot. We submit (by FTP) a text file with an expected format using carriage return and line feed to separate data entity requests.

From C# this means shelling out to a batch file (remember DOS) which executes some Java code responsible for handling request/response. If the request is valid then one minute later a zip file is returned that contains a text file. We parse and we have a database ready data file. If the request is badly formed, however, then an error file is created on the remote FTP directory but that is never returned!

Five years ago someone asked on WILMOTT (serving the Quantitative Finance Community) how to connect a Java application with Bloomberg to send and receive data. Dominic Connor was kind enough to reply.

At another time, at another place we used the DLLs on the Bloomberg terminal to return the data we needed. It was fast, efficient, predictable and illegal. Good times.

You may be here looking for something on bbdlftp or BBDL FTP. Good luck.

First take involved opening solution in Visual Studio 2008 and publishing to localhost and then using FTP to send files individually whereupon we discover that using O2 mobile broadband (via USB) results in files arriving "successfully" on remote web server with file size 0KB. Yuck! Many more takes to replace "successfully" transfered files. Don't blame FileZilla because it's doing only as it advertises and we've had issues with FTP ourselves quite recently from within code we'd written.

Digression: It was necessary to compare file content between local and remote files before assuming successful transfer. Not pretty. Never discovered a better solution that didn't involve MoveIt.

Finally everything copied across and directory turned into Web Application using the DiscountAsp.Net unsurprisingly named Web Application Tool. Instead of blog appearance we have this compilation error!

So it turned out there are at least two ways of resolving this without trying to understand intricacies of ASP.NET Dynamic Compilation and being frustrated by not being able to delete Temporary ASP.NET files on a remote server which denies access to said directories and probably with good reason. Wondering why WebDAV isn't an option here though... probably a good reason I'm not aware of.

• Twenty One step program on How to Convert BlogEngine.NET Web Site to Web Application Project; or
• Follow these instructions on How to Install BlogEngine.NET (which I reckon counts as a single step)

If you see this then everything's turned out okay. Global warming has been corrected. If you care in even the slightest this application defaults to using an XML file datastore and so we need to weigh up whether there's any advantage to pushing this into SQL Server. Climb the mountain because it's there? Okay, it's probably not quite a mountain and we'd not do it in a tutu.

Notes:

MSDN: Understanding ASP.NET Dynamic Compilation

Post Script:

It's a love/hate relationship with Infrastructure.

• By their being responsible for deployment I'm sometimes spared the headache of failed deployment.
  • In this first instance someone else discovers/solves the problem.

• By their being responsible for deployment I'm sometimes victim of failed deployment.
  • In the second instance someone else *is* the source of the problem.

Poetry very incidental.