Another x-plat CLI option is Piggy - https://github.com/datalust/piggy - a side-project still early days of development, but may be interesting for the lack of (e.g. JVM) dependencies. It's a self-contained binary for Win/Mac/Linux.

DbUp, upon which Piggy is based, is a popular option in the .NET space: https://dbup.github.io/.

(Neither attempt the protections that I think strong_migrations is offering - TIL!)

https://github.com/serilog/serilog-settings-configuration (JSON) and https://github.com/serilog/serilog-settings-appsettings (XML) should have pretty much everything covered - anything particular missing? Cheers!

If these https://github.com/serilog/serilog-settings-configuration/bl... https://github.com/serilog/serilog-settings-appsettings/blob... are more or less what can be done, than yes, comparing to NLog configuration possibilities Serilog is very weak. I do not position myself as NLog expert, but I had time to learn it and use in complex scenarios, so just opened NLog.config of one of my project and here is what I use. The following is not NLog vs Serilog comparison, it is very brief "what I use in NLog" vs "what I did not find in serilog by just viewing files in browser".

So, I want everything to be configured from config file and changed after program is compiled.

* Asynchronous wrapper for any log target with some parameters to tune if necessary. * Colorful output to console (separately to stdout and stderr). I can specify colors based on event properties using condition attribute. Using conditions applies to other log targets and other scenarios. * For file target I can specify various log archiving option, based on date, counter, rolling counter, etc. Paths can include references to special folders, process IDs, thread IDs, event event properties, etc., not only environment variables. * Did not find any concept of rules NLog has. I want to be able to freely map event parameters (name, level) to targets.

Again, I have no experience with Serilog, so I expect myself to be wrong and least partially.

Thanks for the reply! NLog's configuration story is certainly impressive; I think the differences in approach make them hard to compare directly on some of these however (for example, most sinks based on network I/O do asynchronous batching by default in Serilog).

Just on the topic of console output, you might enjoy the "literate console" - https://nblumhardt.com/2015/06/contender-for-nets-prettiest-... - for a different take on colored console output :-)

Cheers!

Great post. So the follow-up question is, how much work would be involved in mirroring all that in a native UTF-8 encoded string type? :-)

Windows interop, and 8/16 conversions, would obviously be an expense, but ~half the storage requirements of UTF-16 have to represent a substantial CPU/RAM saving.

Guess it's too much cruft and complexity to introduce into .NET now, but who knows? https://twitter.com/terrajobst/status/717935598904807424

Yeah I think the legacy interop is the tricky part, see "Why does C# use UTF-16 for strings?" (http://blog.coverity.com/2014/04/09/why-utf-16/#.V1AT9vkguUl) for example.

Interestingly enough Java just implemented compact strings that can be ISO-8859-1/Latin-1 (one byte per character) or as UTF-16 (two bytes per character). See http://openjdk.java.net/jeps/254 and https://www.infoq.com/news/2016/02/compact-strings-Java-JDK9 for more info.

Ah yes, my bad - the "value types go on the stack" simplification is a bit sloppy. It's a useful way to describe it to make the comparison - but definitely not for understanding C# in this case.

All good. Also, thanks for alt-composition and stateless.

Thank you - was a bit of an unexpected appearance here so getting onto the erm, technical issues, now...

A quick solution could be to host the page as a static page and have a nginx route serve that page.

Thanks - kicked off a resize, that may not have been the best idea. That'll teach me for hanging on to mainframe-era blogging technology :-)

Mainframe-era blog tech, eh?

http://www.coboloncogs.org/INDEX.HTM

I needed that laugh!

And some good news, serving a static copy from the original domain/URL, so all might not be lost :-)

It's funny until you run into a group of people actually using COBOL to run their website.

HTML caching at nginx level would do the trick as well, assuming you have enough bandwidth.