Nimble GeckoBlog of an upside-down developer, Art Skvira

Handling of URLs and URL parameters in ASP.NET Core is done via Routing Middleware. That’s what Microsoft wants you to believe: Routes in ASP.NET Core provide capabilities of directing incoming requests to route handlers (controllers).

What MS is not telling you, is that Routing also provides copious amounts of reasons to hate it. If you ever said to yourself anything like “OK cool, so I’ll just add a new route for this endpoint, and in no time will go back to the actual task at hand” and then THREE hours down the track when nothing works and your manager is, like, “Have you done it yet?”, you really starting questioning whether this whole web developer career thing is going to work out for you.

As a developer, more often than not you have to deal with other people’s code. And (hopefully only sometimes) you want to throw it all away and rewrite if from scratch. Those of us that are saner (or perhaps just with more battle scars) just roll up our sleeves and get into refactoring. And perhaps you know how awesome it feels to separate someone’s mess of a code into a neatly structured ensemble of classes and corresponding methods, especially when you realise that mess was written by your very self.

When it comes to something as new and quickly changing as .NET Core, and all the other tech that runs on top of it, such as ASP.NET Core and Entity Framework Core, it can be quite daunting trying to keep up with all the changes that Microsoft keeps introducing after finding a seemingly sane and workable solution.

We are naturally drawn towards new stuff - new means better, right? Surely you heard of .NET Core, unless you’ve been living under the rock for the last couple of years. New is hard to resist, especially when it’s backed by Microsoft’s huge PR/propaganda machine. Don’t get me wrong, I am not blaming Microsoft - they’ve got to make sure they attract and retain enough people onto the new platform, but this is exactly the moment you want to stop and ask yourself - what’s better for me, given my task, needs, and constraints?

It is very common in our day and age of interconnected integratedness for an application to be reaching out to external services such as email servers, databases etc. This creates a problem – you need to store usernames, passwords, access codes, API keys etc somewhere and mitigate the risks of that sensitive information either not being found or read by a wrong person.

As highlighted previously in one of those articles, it’s easy to get confused and stuck when trying to specify selected or default value for dropdown lists. The problem stems from the fact that, first and foremost, MSDN documentation is terrible for those things, and secondly because of the approach that Microsoft took, trying to build “one-size-fits-all” solution. But let’s not get too philosophical here and get down to the ground.

.NET Core RC2 has been released just recently and while things have somewhat stabilised, there’s still a lot of confusion around the differences between spanking new .NET Core and the older but more stable .NET Framework.

Let’s dive right in, plain and simple: for some reason, you need to make sure that your users don’t enter any non-printable characters into a text input field on a form. Maybe the data needs to travel to far reaches of the known universe, to a remote ancient banking backend system that runs on COBOL and mainframes (fueled by the energy of a dying brown dwarf). Or maybe the column in the database where this data is going to end up has never heard of Unicode. Or maybe that’s just one of those unexplainable, irrational so-called “business rules”, that some aspiring manager somewhere up in the ranks decided to implement.

It’s a fine day, your site runs smoothly, thanks to Jekyll with its static HTML generation and your clean and clever markdown. Then for some reason you decide to have a look at the Google Analytics Organic Search report and suddenly you see that your traffic just jumped off the cliff.

Sometimes, when errors or exceptions happen you can’t just attach a debugger to your web app - for example, errors may happen only in production, and you can only sit and watch the error logs fly past, or sometimes there are even no meaningful logs available. Maybe you need to debug a closed system - proprietary component/NuGet package that fails. Maybe it’s a combination of several factors

• licenses, data, environment settings, external processes - all that makes local error replication really hard or impossible.