There are 2 or 3 different implementations of the logging repository – one that covers the windows logs, one that writes to azure service bus, one that writes to nothing (and in-memory one used for testing). I thought about using Logentries as place to write the messages to. I created an account and set up my first log

Note that the log also gets a token (a guid) that I will use to send messages to the log at the bottom of the page.

I then fired up visual studio and created a new FSharp project and added a reference from the CSharp project to the FSharp project. I then added an associated unit test class to the existing unit test project:

I then went back to Logentries and read the api documentation about posting to the log here. They suggested either log4net or NLog. For no particular reason, I picked NLog. I fired up Nuget and installed the Logentries.NLog package

I then read further down the documentation and yuck, there is tons of places where you have to add to the configuration file. I am trying to maintain a clean separation of concerns in the app and this intertwines the working code with the .config file. Also, the other implementations don’t use the .config so I would like to keep consistant there. After bouncing around in the api for a bit, I went to stack overflow and asked if there was a way I could implement without the .config file. Sure enough, the dev team was kind enough to answer. I went ahead and implemented their code (after porting it from C#) in my project like so:

After some back and forth with the Logentries team, it became clear that the thread was terminating before the Logentries library had a chance to post it to the service. This was proven by adding a Thread.Sleep to the test:

So what to do? The api does not have an async implementation so I can’t await it and if I leave that Thread.Sleep as is, the main thread will be blocked. I decided to add an async implementation to the interface

And sure enough, green (note that the async test takes longer than 500MS) and the expected side-effect:

So now another CSharp shop has some FSharp sprinkled into their code base. Note the code actually used is slightly different b/c the code as written will keep adding more and more targets, which is not what we want.