ASP.NET Core
Background
Most of us are all “slackers”, meaning we truly do spend a significant amount of time using Slack.
Slack is a collaboration hub for work, no matter what work you do. It’s a place where conversations happen, decisions are made, and information is always at your fingertips.
<a href="https://www.slack.com" target='_blank'><a href="https://www.slack.com">www.slack.com</a></a>
It’s wildly popular in the Developer Community! In fact, almost to a fault…people are constantly sharing their “slack fatigue”. I am personally a part of roughly twenty slack workspaces. One of the really cool features of slack is the ability to integrate with the tool itself through the Slack API. Imagine a plugin playground where you’re free to extend the capabilities of the slack ecosystem. Look to the
<a href="https://api.slack.com/" target='_blank'>Slack API</a>
.
I’m proud to share that this post is part of the C# Advent Calendar and it’s my second year contributing to it! I encourage you to check out all the others
<a href="https://crosscuttingconcerns.com/The-Second-Annual-C-Advent" target='_blank'>here</a>
.
Developers Are Lazy
In the world of web development it is hard to escape certain tools that we are forced to rely on. As developers we’re innately lazy and it is safe to say that perhaps we don’t really care enough to look into other tooling options. Let’s face it… you’re lazy, and I’m lazy and that is all there is to it. .NET Core offers
<a href="https://aka.ms/global-tools" target='_blank'>global tooling</a>
, much like NPM you can use these tools for various build automation tasks. It’s worth exploring .NET Core Global Tooling to see how it might enable us to be even more lazy!
Inspiration
I recently returned from Charleston, South Carolina – where I spoke at SyntaxCon. The event was very professionally organized and gave me inspiration for Cream City Code. In the main hall, they had a HALO by
<a href="https://www.simplebooth.com/" target='_blank'>Simple Booth</a>
. It serves as a photo booth with a conference-specific backdrop – which is perfect for sharing the conference experience. I looked into purchasing one but was encouraged to simply write my own… so I did and this blog will detail that process.
Intro
As a developer, I can say that developers are lazy - at least I know and acknowledge that I am. If I’m tasked with something even the slightest bit repetitious I’ll script it out, or find a way to automate it. Likewise, if I fall into a habit of forgetting something important - I’ll figure out a way to not forget. Especially when it comes to securing an application.
Being a software developer, it’s in our nature to configure various aspects of the applications that we write. With ASP.NET Core configuring our applications is really straight forward. Luckily, there is a lot of really well written documentation surrounding this topic.
-
<a href="https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration" target='_blank'>ASP.NET Core - Configuration</a>
-
<a href="https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options" target='_blank'>ASP.NET Core - Options</a>
However, there is still room for improvement. I’ve prepared a few tips that can enhance developer productivity by taking advantage of various C# features.
Overview
In .NET it’s really easy to create your own interfaces and implementations. Likewise, it’s seemingly effortless to register them for dependency injection. But it is not always
obvious how to override existing implementations. Let’s discuss various aspects of “dependency injection” and how you can override the “framework-provided services”.
As an example, let’s take a recent story on our product backlog for building a security audit of login attempts. The story involved the capture of attempted usernames along
with their corresponding IP addresses. This would allow system administrators to monitor for potential attackers. This would require our ASP.NET Core application to have
custom logging implemented.
Overview
Like the title claims, if you’re using ASP.NET Core and expecting the Thread.CurrentPrincipal or ClaimsPrincipal.Current to be populated you’d be wrong. This is not the
IPrincipal you’re looking for. In this post we’ll discuss what happened and what you need to do now. Additionally we’ll cover all the peripheral benefits as a result of this change.
History
If you have ever done any .NET Framework development, you’ve probably seen the Thread class. You’re probably familiar with the
<a href="https://msdn.microsoft.com/en-us/library/system.threading.thread.currentprincipal" target='_blank'>Thread.CurrentPrincipal</a>
member. This member of the Thread class is defined as follows:
Intro
If you’re a web developer, chances are you’re familiar with optimization strategies such as static file caching and response compression. I recently implemented these two concepts in
tandem on an ASP.NET Core application that I have been developing… I’m going to share what I have learned.
If you haven’t had a chance to use ASP.NET Core yet, you’re missing out! As my friend Scott Addie likes to say:
ASP.NET Core is a cafeteria plan in which developers choose application dependencies à la carte. This is in stark contrast to ASP.NET proper, where developers
are provided a set meal (a bloated dependency chain) containing undesired items. Don’t like broccoli with your steak? Maybe it’s time to consider ASP.NET Core.
Scott Addie
Introduction
As I’m sure you’re all aware by now, Monday June 27th was a
special day for those of you who were anticipating the release of .NET Core and ASP.NET Core. While the “core” frameworks and runtimes are RTM, the
tooling is actually still in preview. In fact, we’re currently on Tools Preview 2. I wanted to focus this post entirely on one specific enhancement
to Visual Studio solutions, enter the global.json.
Introduction
On Monday, May 16th 2016 there was an amazing announcement from the .NET Blog team!
Announcing .NET Core RC2 and .NET Core SDK Preview 1
This post will serve as a guide that walks you through the steps as I experienced them from migrating existing ASP.NET Core RC1 applications to ASP.NET Core RC2.
It is worth mentioning that I’m am targeting the .NET 4.6 framework. So, I do not cover the .netcoreapp or netstandard TFMs (target framework monikers).