For the last year or even more I've been waiting for "usable" build, beta, release candidate, whatever, of the new Core .NET framework and tooling support.  I played with RC1 and betas before, but always had so much trouble in configuring everything, from configuration of project file to producing DLLs and nugets. Specially figuring out various target framework names and standards (dnxcore, net standard, etc – that’s still a mystery too me mostly!). 

Also, lot of things have changed along the way. Since whole development process is so public now, we can see all the changes, mistakes, proof of concepts, some more changes, which were happening behind closed door before where we would just get final RTM bits. So there's that price we as community had to pay, going from DNX and DNU to CLI,   project.json going away soon, who knows what else ...

But I guess, important thing is that framework bits are stable and ready for production use! Runtime, web server (Kestrel, RIP Helios btw), MVC and WebAPI are good to start serious development. Also, Visual Studio for RC2 works fine, which is absolutely necessary for any serious work. 

Lot of blog posts have been written on this topic already, but I would like to point few things which are important now, for us, normal developers working in some company:

• whole new platform to learn & explore: we can now develop on Mac, host on Linux, even run Sql Server on linux! I would say it's a big and important change, going from (not always so) easy-to-use point'n'click server interface to bash command line. It's so serious thing that even Win 10 includes full bash support now!
• new tools available on linux: things like nginx, haproxy, which are mandatory for ASP.NET on linux - you shouldn't expose Kestrel to public! Then different databases, from awesome PostgreSql (my bets are on that one, combined with Marten for NoSql story), Redis, Cassandra, and list goes on ... We have to switch from "IIS application server" mindset to docker style of deployment, with chef and puppet0 for configuration management. That leads naturally to bunch of small services instead of few monolithic one, and that involves service discovery tools like zookeeper and consul.
• To be honest, as a .NET dev I was really jealous on all linux-platform devs for last few (10?) years! They had docker, bunch of fancy data stores, mezos, big data tools, bunch of analytics and logging tools (Kibana, Kubernetes) ... while we (windows server centric) developers where totally isolated, there's whole brave new world of tools, frameworks and services emerging and we're still fighting with MsBuild and MsDeploy and Sql Server. I will not even mention MSMQ here. I don't want to find myself in "who moved my cheese" position, and it looks I'm awfully close.
• actors. Really important concept, not the silver bullet for every use case, but it has it's place. Microsoft is pushing that also with Azure Service Fabric, with statefull and stateless variants of actors and services. Akka in JVM (java and scala) is quite successful, and even though we had Akka.net it really never became "mainstream" framework. Personally, think it's not the problem with akka.net itself, but with regular-Joe-.net developer, who uses only what MS releases.  There's Orleans framework, but it's made for specific use case (Halo game on Azure) and should be avoided for general usage IMHO.
• cloudify all the things. Most of the companies where i worked are slowly switching to the cloud. That brings scaling, resiliency, failover to the list of non-functional requirements. Application needs to be designed differently to accommodate almost-certain outage and downtime of a service, and also to control overall costs.  

What I Like:

• new domain http://dot.net is totally cool
• VS Code, since VS Full + Resharper can be unusably slow sometimes. It will force me to learn how to program without Resharper :)
• exposure to Linux
• new modular and minimal design of .NET, and whole cross-platform support
• attention to performance. Just to show off how "my framework is faster than yours" when talking with other devs. Important stuff.
• Xamarin will get proper attention now, when it’s part of the same company.
• community standups, great way to hear what’s going on and ask questions

What I Don't Like:

• changes beta -> rc1 -> rc2. RC2 looks like real beta to me. Think it could be communicated better, in form of; what's todays state, how to install nightly builds and use that with VS Code, what's working and what's not, what are all the "net standard" targets and what the hell do they mean, etc. Community standups are great, but I would like to have one up-to-date web page describing how to setup dev environment and how to pick right target framework
• Xamarin and .NET Core – I’m guessing some merging will happen, this way it just doesn’t make sense to have 2 frameworks and runtimes doing almost the same job
• VS becoming even more slower. Has many problems with Update 2, had to completely reinstall VS on one machine, and even reinstall whole Windows on another!
• whole .NET could be released in more "agile" or incremental way: first core bits, then standard library (one nuget at the time!), then app frameworks like MVC, and so on. So not wait until everything is RTM (framework, web server, libs, tooling, EF, Xamarin, ....) but bunch of small RTMs. Until MVC is RTM, we would have many libraries and frameworks already ported and ready. I think MS is here aiming at regular dark-matter developer who wants the whole package of absolutely everything, but this is framework for next 10y, customer shouldn't be a developer from 2006.
• like Json.net become a part of official .net, i would like to see more examples like this: for logging (Serilog?), messaging (EasyNetQ?), database (dapper, marten), architecture (akka.net), where MS officially endorse and support some OSS project. I don't mean full SLA where I can call MS in the middle of the night and ask some crazy question, but more from marketing perspective (if that's even possible or makes sense) 
• Win 10 issues: forced restarts, burned by those several times. Lack of High DPI support. Not related to .net, but I'm just so angry about this. If high DPI doesn't get fixed soon, I'm switching to Mac book.

RC2 is out, VS Code and VS Full have full debugging support, there's no excuses any more to try new platform! It's a call to action!

Looks like 2016 and 2017 will be years of learning new platforms, environments and tools! Maybe it sounds scary, but I can't wait:)

It usually goes like this:

• Lets hack a prototype or proof of concept
• Deploy to production
• The hell, people are visiting my web site and I didn't add any application logging!

Happens to me all the time. I'm adding some logging framework when it's too late, users complained, site went down, don't even know what happened! Not really sure why is that, but my theory is that most popular framework requires XML configuration in web/app config, and it's often very difficult to find all the config options, so I tend to leave "logging feature" for the end. I also hate XML-based configuration for those types of stuff. Some logging framework supports code-based configuration, like Serilog.

Some options for logging are:

• Elmah - really easy to add, but logs only exception
• Nlog or Log4net - really similar frameworks, more of a personal preference which one to use
• Serilog - interesting new framework, easy to use code based configuration yay!
• AppInsight, New Relic, Splunk - much bigger and complex solutions and services, can be plugged in to some other framework like nlog or serilog, as a storage of events. They offer whole set of analytics, diagnostics and reporting tools. Really useful feature of those are ability to log server events - number of web request, memory consumptions, database requests and timings, etc

No matter what framework you pick, it's important to set API over logging right, and then implement it in the framework of your choice. In one of my recent projects, we created logging semantics in two dimensions: level and type:

• Level is standard logging level like verbose, debug, info, error, etc
• Type is something that describes an event, provides better semantics about the event, and can be, for example:
  • Diagnostics - system and application related events
  • Operations - business related events
  • Performance - benchmarks

So every log event needs to describe also those two dimensions; level and type. Translating that to an interface, it can look like:

Some logging frameworks and services like Serilog and Splunk supports storing of structured objects (DTOs) into a store, which are then later available for querying. That can be really useful feature, since those objects are stored in their "native" structure (JSON) inside NoSQL store, they are not flattened into one string, all information are preserved (think of queue messages, commands, requests, that can be stored and later inspected in case of a problem).

To support sending of objects API can be expanded little bit:

void Log(LogLevel level, LogType type, string message, params object[]  data)

There's one more neat trick that can be used to make API semantics little bit better and easier to use; we can add extension methods to for ILoggger:

And so on. You get the point:)

With  those extension methods, usage can look like this:

which will result in log entries that can look like:

14/10/2015 7:00:00 [Info] [Operation] Trying to pay the order { OrderId:1, Prop:1, Prop2:2, …}
14/10/2015 7:00:01 [Error] [Operation] Error processing payment request
  full stack trace of exception…
14/10/2015 7:00:10 [Debug] [Performance] Payment service executed in 1234ms

with log entries like this, it much easier to get the context of the entry. We can search for all Performance entries for example, and find bottlenecks, or get only business related (Operation) entries and filter out technical one.