0 Comments

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:)

0 Comments

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.

1 Comments

.NET platform is currently undergoing a lot of changes, probably biggest one for web developers since .NET 1.1. To understand what are bits and pieces people have to dig through presentations, msdn blogs , announcements and conference videos, because as usual MS PR department is too busy promoting something else I guess (not Windows Phone, that's for sure also). If there were no Scott Hanselman, Scott Hunter and Damien Edwards I would probably be still scratching my head;)

At the time of writing this text, this is what we as community know:

.NET 4.5, 4.5.3, .NET 4.6, .NET 5, .NET …

If you create a new project in Visual Studio 2015, you'll see one new item in the frameworks list, and that's 4.5.3. Also named 4.6 Preview on some sources. It comes in two variations: Full CLR 4.5.3 and Core 5 (switch between in command line with KVM, or just right click to your project in VS, and open properties). 

.NET 5 or "Core .NET" is a subset of 4.5.3, cross-platform (meaning you can call Microsoft directly if your app has problems on Linux, and works on Windows for example. And you have support contract of course) open sourced and under .NET Foundation, created for new ASP.NET 5 runtime. Simply put: 5 < 4.5.3

Created on foundation of fallen Silverlight, since it had CLR runtime for running .NET cross platform (I heard this info on some podcast, forgot where and when. Please share some light in comments on this if you know, maybe I'm completely wrong!). Pragmatic and understandable approach, if I may add.

Relies on famous OWIN spec, a delegate described simply:
var middleware = Func<Dictionary<string, object>, Task>

bent by Microsoft a little bit to suit the needs of a platform and app development (probably still ongoing conversation about definition of iAppBuilder, IApplicationBuilder, Startup class, what should be in there and what not; where the line between vendors implementation and what is part of a spec), but everything built on top of .NET 5 / ASP.NET 5 can rely just on that middleware delegate, no more ties to OS. Whole framework has around 10MB, so as you can imagine, lot of things are missing, like WCF, WebForms, WPF, …

Just remember, if you’re building something that has to be cross-platform, don’t depend on IApplicationBuilder, but just on OWIN delegate, and add registration to execution pipeline (appBuilder.UseXY()) as an extension method.

ASP.NET vNext

Currently, on .NET Core 5 (ASP.NET 5, or ASP.NET vNext or just vNext) you can run: MVC 6, WebAPI2, SignalR, WebPages, NancyFx, and the whole thing (Core 5, Kestrel, Helios, Configuration, projectless projects, DI, Roslyn on-the-fly compilation…) is named ASP.NET vNext. It's still under development, but even though surface API stabilized in last few months, it's not ready for production.

MVC 6 project template includes Entity Framework 7, which is in alfa stage (Jan 2015) , and like Full .NET Vs Core .NET, it contains only subset of features from EF 6. Looks like a step back but it's really a complete rewrite of almost 10 years old ORM which was just too heavy and complicated to maintain and expand.

Also, Core 5 doesn't run WebForms, and i think it never will (reminder: change this sentence if I was wrong).

So long story short: .NET 5 is bin-deployable usb stick-portable subset of 4.5.3. It's cross platform and can run only new MVC 6. For everything else, use 4.5.3.

Entity Framework 7

Entity Framework 7 in first version will not support bunch of "advanced" features from v6, so think about it as Light EF MicroORM vNext v1. Looks like EF, smells like EF, but doesn't compute like EF.
Works on 4.5.1+, where EF 6 doesn't work of Core 5. I would use it just if I have a good case for it, for example I want to run my app on the WinPhone. When it’s finished, it will work with NoSQL document storage (Azure Table Storage will be one of the first supported stores), Sqlite and PostgreSql (awesome db!), other providers are expected after the release. Final release is expected after Core 5, so don’t really know what will be bundled in MVC 6 RTM template; EF6 doesn’t work on vNext, and E7 will not be RTM ready till then.

KRE

Windows always automagically knew how to spin up CLR runtime when we double clicked on .NET created .EXE or requested an ASP.NET app through IIS. On Linux we have to write “mono …”. And now with cross-platform Core 5, we have KRE runtime loader (K Runtime Environment) to do that. It's also used as an application host instead of good ol' rusty System.Web, and for running Roslyn to compile on-demand or on-the-fly.

KVM

K Version Manager, used to switch CRL runtime, or KRE. Useful commands to upgrade or install KRE can be found here https://github.com/aspnet/Home/wiki/Version-Manager. In the future we will have several versions of CLR runtime, and we can just switch between them, or upgrade any with simple command. I’ve seen this in Python world, looks and works great there … 

KPM

K Package Manager. Like Nuget, just works (finally) without Visual Studio (Nuget prior to v3 relied heavily on Visual Studio for adding references to a project and bunch of other stuff, for example).

There are two important commands to remember:

KPM restore - restores all the packages defined in project.json

KPM pack - pack your app in self-contained deployable directory

Katana

When OWIN was drafted and reached v1, Microsoft needed an "adapter" to run OWIN-based apps on top of ASP.NET 4.5, meaning System.Web. And that's Katana, created as temporary solution until we get final Core 5. Contains hosts, servers and middlewares so we can run OWIN apps on IIS, self-hosted with HttpListener.

Don't quite know what will happen with it, but it seems we'll need those set of libs if we want to run OWIN apps on full CLR 4.5.*

Helios

For every request IIS calls into System.Web, which heavy architecture optimized for big statefull web apps (that's how they envisioned web should work in 2000.) is just not optimized for many small request and todays usage scenario (REST, microservices, etc). OWIN is free of System.Web, so new server for hosting ASP.NET on IIS could be built, and that's Helios. It uses around 3kb per request, compared to 30kb of System.Web, enables a lot more concurrent connections per server. Think of Node.JS performance, or even better.

Nuget package is Microsoft.AspNet.Loader.IIS, and runs on IIS and IIS Express

Kestrel

Like there's a Helios for IIS, to server request on Linux there's Kestrel (works on Windows also). Built on top of libuv, cross-platforms asychronous I/O, battle tested offers and with great performance. Libuv uses single threaded event loop to receive incoming request, which are then handled over to .NET thread pool.

It’s important to use it properly and not just expose Kestrel HTTP endpoint to public, but rather keep it behind some "real" HTTP server, like Nginx.

Nuget is Microsoft.AspNet.Server.Kestrel.

 

Hope I shed some light on current platform state, since everything is kind a moving targer right now, or needs an overview. In few months things will be much clearer, and until then…

One more nice and confusing picture with lot of geeky information that explains everything and nothing in the same time: