Early in a web app project, I decided to use Nlog as my logging solution and really like the idea of just making calls to a logger class in my code and then decide at run-time what and where to log. Then we decided that this app should be hosted in Windows Azure in a Web Role, to take advantage of all that offers. Now, I realize that Nlog isn't going to work the way I had envisioned it. Here are the issues raised by the change:
- It can't log to a text file in a standard log folder, because the folders are read-only, and even if they weren't, they'd be instance dependent and not persistent because of the way instances and instance local storage is provisioned and will disappear on recycle.
- Because these config files are read-only, I can't take advantage of the most powerful feature of Nlog, that being the ability to decide at run-time how to configure the output.
I have found some solutions to the issue of where to log. Either configuring a target to log to the Azure Diagnostics table or to the role's table storage. While this may be the way we have to do it, it seems very limiting, because it would seem that you can only log to a single table (diagnostics or custom table for the role). Is anyone aware of a better solution? Logging to an AzureSQL database would be too expensive.
Also, how could I configure Nlog, if I wanted to temporarily log to a database or SMS, email, etc., if I can't edit the config file. I know you can store info in the ServiceConfiguration.cscfg file and it is accessible and editable at runtime, but AFAIK, that's not an option for Nlog configurations. Is there a way to edit a deployed web.cfg or Nlog config file for all instances?
Because of these limitations, would it be best to scrap using Nlog, and go with a different, more compatible logging method?
