Seb Nilsson

dotnet-ping: Ping URLs in the Terminal

Mon, 14 Oct 2024 06:44:00 GMT

When working with the web development at a rapid pace, you need to constantly ensure that key parts of your website always work. There are tools out there that offers advanced monitoring, but what about when you just want to fire off quick ensuring tests on your local machine?

This is the background to why I built dotnet-ping, which is easily installed as a .NET Global Tool and makes pinging URLs via the terminal really easy.

Installation

Download the latest version of .NET. Then install the dotnet-ping .NET Tool, using the terminal:

dotnet tool install -g dotnet-ping

Once installed, you can verify the tool is available by running dotnet tool list -g.

Basic scenarios

To ping a single URL just supply the URL as the command argument:

dotnet ping https://example.com/section/page

If you want to ping multiple URLs, you can supply multiple command arguments.

dotnet ping example.com/page other.com/other-page

If a URL is missing the protocol (e.g., http:// or https://), the tool will automatically assume https://.

You can use the -s option to set the sleep time between requests and the -t option to set the timeout limit for a response from the pinged URL.

If you want to ping multiple pages on the same website, you can supply a base-URL, using the -b option:

dotnet ping -b example.com /home /about /contact-us /products

Pings expect, by default, a 200 response as HTTP status. This can be modified with the -e option. The full list of documentation can be found by calling the tool with the -h option or looking at the README on GitHub or on NuGet.org.

Advanced scenarios

For more advanced scenarios, where you want to have a better overview and more complex configuration for multiple URLs, the tool supports configuration via a .json file. If there is a ping.json file in the directory that the tool is executed from, and no URL is passed as a command argument, this file will be used.

The basic structure of the file allows an array of URLs (urls) and their configuration, as well as an array of configuration group (groups), which are applied to one or multiple URLs.

{
    // Single URLs, with Single configurations
    "urls": [
        {
            "url": "test.com", // Required
            "method": "GET", // Default: GET
            "timeout": 15000, // Default: 5000ms
            "sleep": 100, // Default: 500ms
            "expect": [ 200, 201, 403 ] // Default: 200
        },
        {
            "url": "http://test2.com",
            "method": "DELETE",
            "timeout": 10000,
            "sleep": 200,
            "expect": [ 201, 202, 204 ]
        }
    ],
    // Groups of configurations, with single or multiple URLs
    "groups": [
        {
            "timeout": 20000,
            "sleep": 250,
            "expect": [ 301, 302 ],
            "urls": [ "test3.com/redirect", "test4.com/redirect" ]
        },
        {
            "timeout": 5000,
            "sleep": 550,
            "baseUrl": "https://test5.com/",
            "expect": [ 200, 201 ],
            "urls": [ "/", "/about", "/contact", "products" ]
        }
    ]
}

Usage Documentation

See the usage documentation of the tool by running dotnet ping -h:

USAGE:
    dotnet-ping [urls] [OPTIONS]

EXAMPLES:
    dotnet-ping https://example.com
    dotnet-ping https://example.com other.com -s 1000
    dotnet-ping https://example.com other.com -s 1000 -s 2000 -t 5000
    dotnet-ping /about /contact -b https://example.com
    dotnet-ping -c ping.json

ARGUMENTS:
    [urls]    The URLs to ping. If not specified, the URLs are read from the JSON config file

OPTIONS:
    -h, --help        Prints help information
    -b, --base-url    Sets the base-URL to use for requests
    -c, --config      The path to the JSON config file
    -d, --debug       Use debug console messaging
    -e, --expect      Sets the expected status code of requests. Default: 200
    -X, --request     Sets the request method. Default: GET
    -m, --minimal     Use minimal console messaging
    -s, --sleep       Sets the sleep wait time between requests in milliseconds. Default: 500ms
    -t, --timeout     Sets the timeout for requests in milliseconds. Default: 5000ms. If two values are provided, a
                      random number between the two numbers will be generated for each request

Outro

Take it for a spin and feel free to give feedback on the tool. If you find bugs or have suggestions, feel free to open an issue on GitHub or submit a pull request.

You can find the source-code on GitHub and the package on Nuget.

How to Understand Log Levels

Sun, 05 Sep 2021 12:27:00 GMT

Originally written and published for Lightrun's best practices

More than once, I've heard experienced software developers say that there are only two reasons to log: either you log Information or you log an Error. The implication here is that either you want to record something that happened or you want to be able to react to something that went wrong.

In this article, we'll take a closer look at logging and explore the fact that log levels are more than just black or red rows in your main logging system. When used correctly, they let you filter certain types of data to be logged to different destinations, have different retention times, and can be searched more easily in different structures of the data.

Why Logging?

While developing software, hopefully you write unit tests to validate isolated functionality in your code, add some integration tests, and maybe do some manual testing on top of that. But when your code is running in production, you need a way to get information about what code is being executed inside your software and have that accessible from the outside.

The most common way to do this is to add logging to your code. Usually, this code will then write to a destination, which can be a local file, a database, or a centrally controlled more advanced log solution. You can then access this information to get technical insights into what's going on in the running code.

Log entries, depending on configuration, usually contain a time stamp, a severity level, a message entered in the code, sometimes which class/file is doing the logging, sometimes a stack trace from an error in the code, and other metadata about the execution context. When done right, this can help developers follow the flow of logic through the software.

Many use logging to log key events in the system, like orders completed, users registered, reviews written, and so on. With correctly structured data, you can pipe this data into different analysis tools to get more business insights. For example, usually, you turn to your logs when something goes wrong in the software. If logging is set up correctly, you'll be able to figure out where the problem comes from and from which line of code.

If there's not enough information in your logs, you might want to ensure that a lower level of logging is written to your logs, so you can get more details about what's going on in your software. You can usually achieve this by using different log levels.

Understanding The Different Log Levels

Log levels convey the intention of the specific content of what's being logged. This can help you filter different levels of log data into different destinations, enabling you to focus on the log level relevant to the current issue you're facing. Logging to different destinations also allows you to have different retention levels for different logged content.

These are the most common log levels for logging libraries:

Critical*
Error
Warn
Info
Debug
Trace

* Sometimes under other names, such as Fatal or Fault.

Different languages and platforms, and their most popular logging libraries, actually support different log levels, even if the core functionality is there across them all.

	`Trace`	`Debug`	`Info`	`Warn`	`Error`	`Critical`
C#/.NET	✔️	✔️	✔️	✔️	✔️	✔️
Java	✔️	✔️	✔️	✔️	✔️	✔️ (as `Fatal`)
Python		✔️	✔️	✔️	✔️	✔️
Rust	✔️	✔️	✔️	✔️	✔️
Swift		✔️	✔️		✔️	✔️ (as `Fault`)
Kotlin	✔️	✔️	✔️	✔️	✔️

Many logging libraries allow you to also handle an All scenario, where all the levels are written to the configured destinations. The None scenario, then, turns off all the logging. Some libraries also support a Custom scenario, where you can specify exactly which log levels to include.

Picking the Right Log Level

There is no right or wrong when it comes to picking a level of logging, but it's important to set the same expectations throughout a project and maybe throughout an entire organization.

Here are a few best-practice suggestions as a starting point that any team should be able to build upon:

Critical: Used when your application is in an unrecoverable state. It crashes during startup configuration, or a framework-level component is not working as expected.
Example: Your app cannot start up correctly or your DI setup fails.
Error: Used for errors that stop the flow of the execution. Usually used for unknown and unexpected errors in a central catch-all scenario for an application.
Example: Routing in your web app fails, or code in an MVC controller throws an exception.
Warn: Used for errors that don't stop the flow of execution. Usually, these errors are somewhat expected, since the logging code is added manually to these points in the code.
Example: Calling an external service, which you know can fail and you can silently recover from.
Info: Used to log events in the normal flow of the code. Can be used for only system key events, to keep the volume of log data down.
Example: User clicked a call-to-action button or new user registered.
Debug: Used for scenarios where the information in higher levels is not enough to debug a problem. Should record the flow through the system.
Example: Method X was called in class/object Y, to track different flows.
Trace: Used to get as much detail as possible, tracking the flow of data through the system. Can contain sensitive data. Should probably never be activated in production.
Example: Method X was called with parameter values Y and Z.

Usually, Critical, Error, and sometimes Warn levels contain a full stack trace for full analysis of the technical context of the problem.

You will probably want different configurations for your logging between your local development environment, your testing environment, and your production environment. It's worth noting that, with most logging libraries, configuring for one level includes the levels above it. For example, if you configure for the Info level, it'll include all levels above it, too, in the logging. So you'll also get Info, Warn (where available), Error, and Critical.

Some libraries allow you to set an upper limit as well, but this is for very specific scenarios, since you would rarely want to see Error logs but not Critical logs, for example.

However, all solutions have different needs, and these needs can change depending on what problem occurs when. Let’s glance through some examples of various setups.

Local Development Environment

In a development environment on your local machine, you probably want to start off with the Debug level of logging. You can lower it to Trace if more detailed issues need diagnosed, or increase it to Info if it gets too noisy.

You'll probably always want to write to local files on your file system for quick access, and avoid writing to any central logging destination, unless you're explicitly testing the integration itself. This is because it can generate a lot of data over time, even with a small team, which usually increases cost quite a lot.

Testing Environment

In a testing environment, which is not on your local machine, you probably want to set the logging level to Info and then temporarily turn the level down to Debug and Trace as needed for the moment. If you're not interested in the normal flow of the app and only want to catch errors, you can actually set the logging level to Error.

As it's a test environment, you should only have test data logging here, so lower logging levels should not be logging sensitive production data. You don't have to worry about that aspect here, even if you should always be vigilant of it.

Since this is not a local machine, you probably don't have (and maybe shouldn't have) easy access to the machine's local disk. This is a good opportunity to use a central logging solution (there are plenty of those on the market at the moment at various pricing levels).

Production Environment

In a production environment, you could start out by configuring your logging to write Info and higher to a centralized logging service, such as a SaaS solution in the cloud. You should consider writing the Error level and higher to local disk files, in case the SaaS has any technical issues. Remember to manage the retention of these local logs to avoid being incompliant with data privacy rules and to keep costs down.

For the very complicated and hard-to-solve bugs, you need to be able to activate Debug and Trace level logging. To comply with data privacy rules without too much hassle, consider writing only these two low levels to local files, which can easily be deleted, and set a very short retention time for them. Always consider using a staging environment first, when using the Trace level and only use the production environment as the last way out.

You can also consider forwarding just the Info entries to an analysis tool of choice, to analyze key business events being triggered in your system. Some logging libraries support sending additional data in their entries, which can make this scenario more powerful.

If needed, you can also configure Error and Critical to log to another external system, maybe another SaaS, that sends out alerts for these log entries. Many existing SaaSes for logging have this functionality built-in, so there's usually not a need for this configuration, but it's good to know it's an option.

This would then mean that you're double-logging between two systems, but since you hopefully won't have a large volume of this kind of log entry, you don't have to worry too much about cost and you're only using the right tool for the right job.

The Caveats of Logging

Logging a lot of data might be the only way to solve some of the craziest bugs created out there, but there are some downsides of logging too much.

Depending on the solution you choose for logging data, too much data could make it very hard to easily search through your logs. If the logging is split into different files for different days (or hours), it's hard to analyze a trend over time.

Normally, no matter what solution you have in place for logging, the more data you log, the higher the cost will be. Even if you're logging to the local disk of the server, space can get used up quickly over time.

There is also a major security risk of leaking sensitive data if you store too much data, with too detailed information, for too long. With all the new privacy rules out there, you also risk being noncompliant for things like GDPR, if you store personal information too long, even in local files.

Conclusion

Logging is something you should include in your workflow right from the beginning when writing your software. Setting it up, and with the right strategy, will enable you to produce well-running software, monitor it in a robust way, and quickly access details about any problems that occur. Just keep the potential pitfalls in mind, such as cost, searchability, and security.

Having a solid strategy for which log level to use for what scenario is crucial for a long-term path growth path for your software. This will allow you to extend your logging in the future, making use of more refined and mature logging tools, as your software grows and the need inevitably shows itself.

Best 20 C# & .NET Blogs

Mon, 21 Dec 2020 14:44:00 GMT

Originally written for and published on the Draft.dev blog

C# is a language loved by its users for being versatile, productive, and keeping up with the current problems programmers need to solve. For example, maintainers have added functional programming concepts to the primarily imperative C# language, adding the powerful query-functionality in LINQ, and smoother handling of asynchronous programming with the async / await-syntax.

The unification of all versions of .NET into .NET 5 has given C# and .NET future-safety, no matter which platform you use to develop or which platform you develop for: desktop, web, cloud, mobile, or other.

Whether you're getting into C# with the launch of .NET 5 or if you're a long-time C# developer, there are a lot of great blogs out there. Based on writing quality, consistency, longevity, technical depth, and usefulness, I've put together this comprehensive list of the 20 best C# blogs publishing today.

.NET Blog

Maybe a bit obvious, but the .NET blog from Microsoft should probably your first place to check for new updates on C# and .NET. They consistently publish updates about everything related to C# and .NET but also dives deep into different subjects, such as functionality deep within .NET or the details about the performance improvements being made there.

Writing Quality: 5
Consistency: 5
Longevity: 5
Technical Depth: 5
Broad Usefulness: 5

Scott Hanselman's Blog

Sometimes, I'm unsure if you're allowed to use .NET if you're not reading Scott Hanselman's blog. There might be something in EULA about that. 😉

Jokes aside, Hanselman has been blogging about C# and .NET from the very start and has inspired many people with the content on his blog, his conference-talks, his podcast, his YouTube-channel, and more. He mixes high-level articles with some technical deep-dives, and his posts seem to be driven by his passion for learning and solving problems.

Hanselman has become quite a household name in the .NET-world and is often featured in Microsoft's keynotes. This is well deserved, given his unparalleled professional approach to quality content, interesting topics, and entertaining delivery.

Writing Quality: 5
Consistency: 5
Longevity: 5
Technical Depth: 5
Broad Usefulness: 5

Ardalis: Steve Smith's Blog

Steve Smith (aka Ardalis) is a strong proponent of producing content instead of consuming it, which is quite obviously something he lives by when you look at his output. If you are a person wanting to build your own brand, Steve is a role-model. He continually puts out qualitative information on his blog, on Twitter, on Twitch, his newsletter, his Pluralsight-courses, and he now also is building his own developer coaching-community.

Lately, Steve has been focusing on a lot of content around Domain-Driven Design (DDD) and the SOLID-principles. Much of this can be found on his blog and on some great Pluralsight-courses.

Writing Quality: 5
Consistency: 5
Longevity: 5
Technical Depth: 5
Broad Usefulness: 4

Alvin Ashcraft's Morning Dew

Want to see basically every new article the community puts out every single day? Well, then Alvin Ashcraft's Morning Dew has you covered when it comes to the subjects of C#, .NET, and the Microsoft-ecosystem.

Alvin Ashcraft is a longtime Microsoft MVP. From what you can tell from comments on his website, Morning Dew is the result of Alvin reading through over 1,600 feeds daily. Any interesting articles found are categorized and published on the blog.

Writing Quality: N/A
Consistency: 5
Longevity: 5
Technical Depth: N/A
Broad Usefulness: 5

Troy Hunt

One of the most influential voices on the topic of security within the Microsoft-ecosystem is Troy Hunt. He is the creator of the service Have I Been Pwned (HIBP), which helps users identify if and how they've been affected by data breaches and other malicious activity on the internet.

Since Troy has Microsoft MVP for developer-security for a longer time, this is a subject that is often covered on his blog.

Writing Quality: 5
Consistency: 5
Longevity: 5
Technical Depth: 4
Broad Usefulness: 3

Tim Heuer

Tim Heuer has worked at Microsoft since 2005, currently with a focus on .NET, Visual Studio, and Azure. This gives him a lot of insight, which you can tell by the in-depth content and a great variety of technologies covered on his blog.

Writing Quality: 5
Consistency: 4
Longevity: 5
Technical Depth: 5
Broad Usefulness: 4

The Data Farm: Julie Lerman's World of Data

Julie Lerman is the absolute authority on Entity Framework, including EF Core. No matter if you're looking for a detailed, low-level problem within EF, or if you're looking for a solid guide to walk you through various aspects of Entity Framework, there is a real chance that you'll find material around it produced by Julie Lerman.

Writing Quality: 5
Consistency: 4
Longevity: 5
Technical Depth: 5
Broad Usefulness: 4

You've Been Haacked

Phil Haack was an integral part of helping Microsoft make many of its development-software open-source, along with Scott Hanselman, Scott Guthrie, and Rob Connery. Since then, Phil has moved on from Microsoft but still consistently blogs about technologies in the Microsoft-ecosystem.

With his experience inside Microsoft during their exciting transformation, there is usually something interesting for developers to learn in his posts.

Writing Quality: 5
Consistency: 4
Longevity: 5
Technical Depth: 4
Broad Usefulness: 4

ploeh: Mark Seemann

If you feel completely bulletproof in your coding-skills, go check out Mark Seemann's blog and get a glimpse of the endless things you could be doing better.

Writing good software is an art, so you can have endless opinions on other peoples' opinions, but there is almost always something new to learn from Mark's deep-diving and well-thought-through posts. Each article walks you through a complicated concept and helps you understand it and become a better developer who writes better, more maintainable code.

Writing Quality: 5
Consistency: 5
Longevity: 5
Technical Depth: 5
Broad Usefulness: 3

Daniel Cazzulino's Blog

Daniel Cazzulino (aka 'kzu') is the creator of the most popular mocking framework for C# and .NET, called Moq, which is used for testing the source-code behind .NET.

Kzu writes about all different kinds of technologies related to the Microsoft-ecosystem and mixes high-level guides with technical deep dives into non-mainstream topics.

Writing Quality: 5
Consistency: 4
Longevity: 4
Technical Depth: 5
Broad Usefulness: 4

Visual Studio Blog

The blog for the Visual Studio Engineering Team, of course, covers everything related to Visual Studio, but it also includes adjacent technologies, which can contribute to great inspiration. They cover topics like Unity, Visual Studio for Mac, GitHub-integrations, debugging with memory-dumping, and much more.

For anyone interested in productivity in your Visual Studio-editor, it's worth noting that Mads Kristensen writes posts on the subject on the Visual Studio Blog.

Writing Quality: 5
Consistency: 5
Longevity: 4
Technical Depth: 4
Broad Usefulness: 4

Maarten Balliauw

Maarten has a focus on web and cloud-apps, but he was also the founder of MyGet and is a frequent speaker at conferences. He brings a unique mix of experiences and knowledge to his blog, which covers many different technologies within the Microsoft-ecosystem.

Writing Quality: 5
Consistency: 4
Longevity: 5
Technical Depth: 4
Broad Usefulness: 4

Jon Skeet

If you have ever searched for a C# question, there's a 99% chance that you have, at least once, landed on an answer on Stack Overflow by Jon Skeet.

He's been the number one contributor to Stack Overflow for many years and usually with a focus on .NET and C#. It is said that he’s read the whole C# specification (maybe more than once), and he regularly blogs about some of the deepest subjects around C#.

Writing Quality: 5
Consistency: 4
Longevity: 4
Technical Depth: 5
Broad Usefulness: 3

Jimmy Bogard

Jimmy is the man behind some of the most productivity-boosting frameworks for C# and .NET developers: AutoMapper and MediatR. These frameworks help you write isolated and more easily maintainable code and his blog-posts revolve around these frameworks, but also these topics in general.

Writing Quality: 4
Consistency: 4
Longevity: 4
Technical Depth: 5
Broad Usefulness: 4

Rick Strahl's Web Log

If you've worked with C# and .NET since its early days, especially with a focus on ASP.NET and the web, you will most probably have run into more than one of Rick Strahl's blog-posts.

In the course of working hands-on solving problems for clients, Rick has documented many solutions to real-world problems on his blog. The topics often coincide with what other people are looking to answer, so you can often find one of Rick's articles linked in answers on Stack Overflow.

Writing Quality: 4
Consistency: 4
Longevity: 5
Technical Depth: 4
Broad Usefulness: 5

.NET Tools Blog - JetBrains

JetBrain's blog for .NET covers very useful topics, whether you use their tools or not. They have specific posts about the popular tools ReSharper and Rider, but also great articles about a broad range of topics related to C# and .NET.

Writing Quality: 5
Consistency: 5
Longevity: N/A
Technical Depth: 4
Broad Usefulness: 4

Shawn Wildermuth

Shawn has been a prolific creator of content around C#, .NET, and the Microsoft-ecosystem since the earliest days of .NET. Focusing mainly on the web-aspect of .NET, and recently, with a lot of Vue.js content, he now describes himself as an author, teacher, and filmmaker.

Writing Quality: 4
Consistency: 4
Longevity: 5
Technical Depth: 4
Broad Usefulness: 3

Fabulous Adventures in Coding - Eric Lippert's Blog

Eric Lippert used to work on the C# language design team, which is clear based on his superhuman rate of answering questions on Stack Overflow. On his blog, he deep-dives into language-design with a focus on "making developers' lives better and having fun doing it".

Writing Quality: 5
Consistency: 3
Longevity: 5
Technical Depth: 5
Broad Usefulness: 2

StrathWeb - Filip W.

When searching for various intricate technical issues related to the Microsoft-ecosystem, it is not uncommon to end up on an in-depth article written by Filip. Recently, the topic of quantum computing has been a big focus, to add to the long archive of articles focused on C# and .NET.

Writing Quality: 4
Consistency: 4
Longevity: 4
Technical Depth: 5
Broad Usefulness: 3

Don't Code Tired - Jason Roberts

Jason Roberts is a former Microsoft MVP who blogs on different topics around the Microsoft-ecosystem. Lately, he’s been focused on testing with posts about approval tests, feature-flags, and optimizing various testing frameworks.

Writing Quality: 4
Consistency: 4
Longevity: 5
Technical Depth: 4
Broad Usefulness: 2

Final Words

While researching this post, I went through every single account I subscribe to on Twitter to pick out the best blogs from the best people I've been following for many years - often over a decade. I was surprised to recognize so many names I had associated with quality content and learned so much from, but what surprised me even more was how many of these people had stopped blogging or switched focus away from C# and .NET.

Scott Guthrie is probably a perfect example. He used to be one of the top bloggers within our field before he was promoted to the fancy title of Executive Vice President at Microsoft, where the blog no longer seemed to be a priority. So subscribe to these blogs while you can. You never know when things will change.

From C# to Rust: Code Basics

Tue, 28 Jul 2020 13:47:00 GMT

Now that we've gotten the fundamentals out of the way, we can finally get into the basics of Rust-code.

This series is written from the perspective of getting to know Rust from knowing C#. There are already many good getting-started-guides out there for Rust, but this series tries to leverage your existing .NET/C#-knowledge to fast-track you into understanding Rust, by relating the concepts to what you already know.

Disclaimer: This series is being written while I'm learning Rust, so I'm by no means an expert and maybe this might be reflected in some of the example code. If you find any blatant errors, feel free to add some feedback in the comments.

Setup

In the post about Rust fundamentals, we could read about how Rust provides a complete toolchain for development, which is made available by installing Rustup, the recommended way of installing Rust.

Create a new project in a command-line by running: cargo new example_project

The file src/main.rs is your application's entry point, which will be run when you execute cargo run. So this is a good file to start with, to follow along in your code-editor. This file will only contain a function called main, with a simple Hello World, when generated by Cargo:

fn main() {
    println!("Hello, world!");
}

Code Basics

Let's start looking at some basic example-code, to go through some basic concepts in Rust. Since Rust is a C-style language, you will probably recognize much of the syntax you see in this code-snippet, as a C#-developer.

You can always find the full code for this series in the from-csharp-to-rust-project on GitHub.

Variables

Variables in Rust are created by using the let-keyword, in a very similar way to the use of the var-keyword in C#.

let title = "Ghost Buster";
let year: u16 = 1984;

Types are inferred in Rust, as you can see with the title-variable. You can also specify the type, as we do with the year-variable, where we want to use a smaller number-type than what is inferred by default.

One important difference between Rust and C# is that variables are immutable by default in Rust. If you want a variable to be mutable, you have to add mut to the variable declaration:

let mut rating_avg = 7.8;

// Someone rated the movie
rating_avg = 7.9;

Variables can be created as constants in Rust, by using the const-keyword, just like in C#. These variables have to have their types specified:

const GOOD_MOVIE_LIMIT: f32 = 7.5;

Naming Conventions

As you may have noticed, Rust naming conventions use Snake case (example_variable_name) for its variables. Unlike C# which usually uses Camel case (exampleVariableName) or Pascal case (ExampleVariableName) for most of its variables, fields, and properties.

The Rust-compiler will even warn you about using the wrong conventions for different namings.

At the moment of writing, Rust-developers also seems to prefer shorter names for variables and functions, than we usually see in C# and .NET.

Strings

In C#, we only have one string-type for all types of strings. In Rust, there are two different string-types you learn about at first. The primitive str-type, which is immutable and fixed length, as well as the String-type, which can be modified and grow in size.

let mut value = String::default();
for x in 65..68 {
    value.push(x as u8 as char);
}
// value: "ABC"

On Stack Overflow, a question called What are the differences between Rust's String and str? the most popular answer, by far, summarizes:

Use String if you need owned string data (like passing strings to other threads, or building them at runtime), and use str if you only need a view of a string.

Conversion between the two types is quite straight forward:

let title = "Ghostbusters";
// From str to String
let title_string = String::from(title);
// From String to str
let title_str = title_string.as_str();

In practical use, you can see Rust's String-type as the equivalent of StringBuilder in C#, while Rust's str is the equivalent of ReadOnlySpan<char>.

Collections

In Rust, the two most common types used to create collections are array and Vec (vector).

The array-type is a fixed-size collection and is compared to an array of a type in C# and .NET, like string[], int[], char[], and so on. The Vec-type can change in size and can be compared to List<T> in C# and .NET.

Both types can be mutated if the variable has the mut-keyword. They can also easily be converted between each other.

let mut arr = [1, 2, 3];
arr[0] = 0;

let mut vec = vec![1, 2];
vec.push(3);
vec[0] = 0;

let arr_from_vec = &vec[0.. 2];
let vec_from_arr = arr.to_vec();

Rust also has the HashMap-type, which is the equivalent of Dictionary<TKey, TValue> in C# and .NET.

let mut map = HashMap::new();
map.insert("key", 123);

Generics

Rust has support for generics, just like C# does, but with a little bit more smart functionality built into the compiler. In C#, you don't always have to specify the exact generics used in some contexts, since it can be inferred. Rust has some additional functionality for this.

For both Vec and HashMap, you don't have to specify the type explicitly when creating the object. It will be inferred by the first items added and enforced to the following added items.

Logic Flow

The if-statements in Rust are very similar to the ones in C#, except you don't need parenthesis around the condition, but it's possible to use it if you want to.

let mut info = String::from(title);

if rating_avg >= GOOD_MOVIE_LIMIT {
    info += " - You're in for a good movie";
} else if rating_avg < GOOD_MOVIE_LIMIT && year <= 1995 {
    info += "- Could be a classic...";
} else {
    info += "... Do you want to look for another movie?";
}

The if-statement is in itself an expression, from which you can catch the result. This means that you can use an if-statement to assign a variable. You can catch the value resulting from the if, the if else, or the else.

This can be used to create a shorthand if. This is a good replacement for the ternary conditional operator (In C#: var a = true ? b : c), since it's not supported in Rust.

let classic = year <= 1995 && !title.ends_with(" II");
let text = if classic { "Potential classic" } else { "We'll see..." };

Pattern Matching

Rust also has very appreciated pattern-matching-functionality. This is something that C# has implemented and seems to keep on improving it with every version.

Pattern-matching in Rust can do a lot more than just replace simple if-statements. It can also, among other things, be used to assign the result to variables. More sophisticated usages will be shown as this series goes on.

let info = match rating_avg {
    x if x > GOOD_MOVIE_LIMIT =>
        format!("{} - You're in for a good movie", x),
    x if x < GOOD_MOVIE_LIMIT && year <= 1995 =>
        format!("{} - Could be a classic...", x),
    _ => String::from("... Do you want to look for another movie?"),
};

Standard Output

To write to the standard output, in the equivalent way of Console.WriteLine in C# and .NET, you use the function println! in Rust.

let hello = "Hello";
let world = "World";
println!("{} {}!", hello, world);

In .NET, we specify the indexes inside the placeholder-curly brackes like this: Console.WriteLine("{1} {0}!", world, hello). These explicit indexes can also be used in Rust like this println!("{1} {0}!", world, hello).

If you don't specify the index In Rust and just use the empty placeholder {}, as in the above example, the index will be inferred.

Just like in C# and .NET, you can add formatting to a parameter by adding a colon-character (:) after it and a specific flag. For debugging, it's very useful to use the debug-formatting, which shows the whole content of the object in the console.

let obj = complex_obj();
println!("Debug: {:?}", obj);
println!("Debug pretty: {:#?}", obj);

Command-Line Arguments

Standard input is not as straight forward as Standard output and not a one-liner like in C# and .NET with Console.ReadLine. So we will get more into that in future articles.

Getting access to the command-line arguments passed to the application is a lot easier. This can be used to quickly build a CLI-type application.

// Execute: cargo run "The Shawshank Redemption"

let args: Vec<String> = env::args().collect();
let first_arg =
    if args.len() > 1 { args[1].clone() } else { String::default() };
// first_arg: "The Shawshank Redemption"

Functions

Functions in Rust work just like in C#, except you declare it using the fn-keyword. You can specify a return-type, but if you don't the function will just act like a void in C#.

fn is_sequel(title: &str) -> bool {
    if title.is_empty() {
        return false;
    }
    let sequel_title = title.ends_with("II");

    sequel_title
}

Notice the lack of a trailing semicolon (;) behind the sequel_title-variable at the end of the method. This makes the statement into an "expression" and Rust will implicitly accept this as a return statement, as long as it's the final expression of the method. This is why a return is needed in the body of the early returning if-statement.

This is a feature that might look weird when you're coming from another C-style language, but that you will see all over the place in Rust-code.

Functions are then called with their names and parameters, just like in C#:

fn main() {
    let sequel = is_sequel("Ghostbusters");
}

Macros

In this article, you've seen the use of the println!-function, with the unusually looking exclamation-point (!) at the end. This annotation makes this a macro. This is a too advanced of a topic to go into in this part about basic code, so I'll just point to official Rust Programming Language Book's section on macros, which summarizes:

Macros are a way of writing code that writes other code, which is known as metaprogramming.

Null-Values

The notorious Billion dollar mistake of allowing null-values into programming languages seems to be a problem tackled only recently. C# got Nullable reference types with C# 8.0 in late 2019 and F# doesn't have nulls built-in at all (even if there are ways to get around it).

Rust does not support null values. Instead, it uses patterns to wrap around types, to help indicate if there was a value or not. The most commonly used such type is the Option-type. It will return either a Some, carrying the value, or a None, indicating there was no object.

fn main() {
    let quotient = divide(123, divisor);
    match quotient {
        Some(x) if x > 10 => println!("Big division result: {}", x),
        Some(x) => println!("Division result: {}", x),
        None => println!("Division failed")
    }
}

fn divide(dividend: i32, divisor: i32) -> Option<i32> {
    if divisor == 0 {
        return None;
    }
    Some(dividend / divisor)
}

Object-Orientation

Object-orientation in Rust is a point in the code-basics where things get a bit strange for the regular C#-developer. In C#, we are used to having a class that owns its fields, properties, and methods. The class is then a template for creating an instance of an object.

Rust uses what they call a struct instead of classes, which is just a "dumb" data-structure, which contains fields, but they do not (directly) contain properties or methods. Instead, Rust provides the possibility to add functions to a struct through the impl-keyword.

pub struct Movie {
    pub title: String,
    release_year: u16,
}

impl Movie {
    // Constructor - Associated method
    pub fn new(title: &str, release_year: u16) -> Self {
        Self { title: String::from(title), release_year }
    }
    // Method
    pub fn display_title(&self) -> String {
        format!("{} ({})", self.title, self.release_year)
    }
    // Method with mutability
    pub fn update_release_year(&mut self, year: u16) {
        self.release_year = year;
    }
}

fn main() {
    let movie = Movie::new("Ghostbusters", 1984);
    println!("Movie: {}", movie.display_title());
}

First, we define the struct and its fields, where we add the pub-keyword to the struct itself and its field title. All public fields are mutable in Rust if used with the mut-keyword by other code. If you want to protect a field, use methods, like the update_release_year-function in this example.

In the impl-block, we have the new-function, which acts as a constructor. It's an associated method to the type, which is the equivalent of a static method in C#. It returns a new instance of the implementing type, which in this case is a Movie.

The function display_title is a method on the instance of the object and through the self-keyword in the first parameter, it can access fields and methods on the object, even non-public ones. It's the equivalent to the this-keyword in C#.

Inheritance

Rust doesn't have inheritance. At least not in the way a C#-developer is used to it. This seems to be a very conscious decision by the Rust-team.

Instead of inheritance, Rust provides the very powerful concept of traits, which allows you to extend any type, no matter if you've created the type or not. As a C#-developer it acts like of mixture of interfaces and extension-methods. We will look closer at traits in upcoming articles in the series.

Ownership & Borrowing

You've seen the use of the ampersand (&) character in some places of the example-code. These indicate that the use of an object is done by reference. This is something you normally very rarely need to deal with in C# and .NET.

This relates to the unique concept in Rust of References and Borrowing. This is the foundational concept which enables the language's memory-safety, performance, and "fearless concurrency".

This is also one of the hardest parts of Rust to master. It's usually the number one complaint about the language from newcomers and a very frequent topic on Stack Overflow and other Q&A-forums.

Primitives Comparison Table

Rust has a set of primitives that overlap quite well with the ones we're used to in C# and .NET. They are listed for reference:

Rust	C#	Comments
bool	bool
char	char
i8, i16, i32, i64, i128	sbyte, short, int, long, (N/A)	Signed 128-bit integer not available in .NET
u8, u16, u32, u64, u128	byte, ushort, uint, ulong, (N/A)	Unsigned 128-bit integer not available in .NET
isize, usize	(N/A)
f32, f64	float, double	.NET has the 128-bit floating-point number `decimal`, which is not available in Rust out-of-the-box
Array	Array	Not a primitive type in .NET. Fixed size.
Tuple	System.ValueTuple / System.Tuple	Not a primitive type in .NET
Slice	Span<T>	Not a primitive type in .NET
str	string	`str` is immutable and fixed length in Rust, but not in .NET
Function	Func<T>	Not a primitive type in .NET

Learn More

If you want to learn more about Rust, unrelated to its equivalent functionality in C# and .NET, you can check out the Learn Rust-section of the official website, which points to multiple resources, including the Rust Programming Language-book and the Rust by Example-book.

I also found the guide Writing Easy Rust very helpful, because it helps to explain the more complicated Rust-concepts in easier terms.

Summary

This article tried to lead you into the Rust-language by relating concepts to the ones you already know in C# and .NET.

Rust is very similar syntactically to other C-style languages, including C#. There are some concepts in Rust that are relatively different from what you're used to, but this can be a great way to be inspired to solve things in new ways. I've actually heard multiple people say that they've rediscovered their love for programming by learning Rust.

From C# to Rust: Fundamentals

Thu, 16 Jul 2020 13:43:00 GMT

There are some fundamental tools and concepts which we should understand before we get into actually coding Rust.

Since this series focuses on Rust from the perspective of a C#-developer, we will try to relate the Rust-concepts to the equivalent concepts in C# and .NET.

Modern Toolchain

Rust comes with a complete toolchain of everything you need to compile and run your Rust-code. All the way from the compiler, to package-management, testing, code-formatting, linting, documentation-generation, and more.

The Rust Compiler

The compiler for Rust can be executed by using the command rustc. This is usually not done by Rust-developers, but instead, it's done through the Cargo-tool.

.NET equivalent: MSBuild / The C#-compiler (csc.exe)

Cargo: Build System & Package Manager

Cargo is used by Rust-developers to manage, build, test, and document their projects. This is done by using various cargo-commands.

.NET equivalent: .NET CLI and NuGet

Cargo-Commands

Cargo can be used to create a new project by running, for example, cargo new example_project.

.NET equivalent: dotnet new

As mentioned above, Cargo builds the project and this is done by running the command cargo build.

.NET equivalent: dotnet build

Cargo is the Rust-equivalent of .NET's NuGet, so it's also used to resolve and download libraries, which it does automatically when you run the cargo build-command.

Now that your code has been built, you can run the code, given that it's a binary. This is done by using cargo run.

.NET equivalent: dotnet run

To just check that the code is valid and if that it can build, but not actually do a full build, there is a more lightweight command in Rust, which is cargo check.

Rustup: Rust Toolchain Installer

To easily get access to the complete toolchain, we use rustup, the Rust toolchain installer, which installs rustc, cargo, the rustup-CLI, and other Rust-tools.

.NET equivalent: .NET Core SDK

With Rustup, you can change which version of Rust is used, install different platforms for cross-compiling, and installing various other components.

Rust on Windows

For Rust and Rustup to work on Windows, you need to install Visual Studio, or the C++ Build Tools and the Windows 10 SDK separately. Details on this can be found on Rustup's GitHub-page.

Package Manifest

When you run cargo new, your new project will get a Cargo.toml-file, which is the manifest that contains the meta-data about your project.

An example-version of the file, with the added dependency to the regex-package, looks like this:

[package]
name = "example_project"
version = "0.1.0"
authors = ["Seb Nilsson"]
edition = "2018"

[dependencies]
regex = "1.3.9"

.NET equivalent: The .csproj-file (or the formerly used packages.config-file).

Node.js equivalent: The package.json-file.

Crates

In Rust, the term crate is used for a package. It can be either an executable binary or a library.

.NET equivalent: NuGet-packages

Crates.io

To find useful packages/crates to include in your Rust-projects, the registry-site Crates.io is used.

.NET equivalent: NuGet.org

Formatting Rust-code

Cargo contains a command which can automatically format all the Rust-code in your project. It's called rustfmt and can be executed by running cargo fmt.

Customizing the rules applied when formatting is done by adding a rustfmt.toml-file to the project, which rustfmt then will follow.

.NET equivalent: There is no built-in way to do this in the .NET CLI, but there is .NET Global Tool from the .NET-team called dotnet-format, which allows you to run dotnet format on your project.

Testing

Running the tests in a project is also done through Cargo, by running cargo test.

.NET equivalent: dotnet test

Testing is built into Rust, so you do not need to add any external testing-package.

VS Code Setup

First, make sure you've installed Rustup. You can verify that you have it installed by running the command rustup --version, which should show you a version-number.

To get started developing in Rust, with features such as syntax highlighting, auto-complete, code-formatting, refactoring, debugging, and much more, you can install Visual Studio Code, with the Rust-extension and the CodeLLDB-extension.

Consider evaluating the extension rust-analyzer as an alternative to the Rust-extension. It's not as well documented, but it seems to have more features, including the showing of type inference.

Next, create a new Rust-project by running cargo new. Now, all you have to do now is press F5 in VS Code and it will automatically create a launch.json for you, which allows you to debug your Rust-code.

Summary

By just installing rustup, we get access to the complete Rust-toolchain. This includes, among other things, Cargo, which lets us work through the full development-cycle with our projects, like: create new projects, compile the code, run the code, format the code, and run the tests in our projects.

Add VS Code with a few Rust-extensions, and you'll have a great developer-experience to get started with.

From C# to Rust: Introduction

Mon, 06 Jul 2020 13:49:00 GMT

Rust has been the most loved programming language for the last 5 years. This, and many other factors, made me interested in learning more about Rust, especially from the perspective of a C#-developer.

Why Rust?

In early 2019, a Microsoft engineer revealed that about 70% of all vulnerabilities in their products are due to memory safety issues. Memory safety is something you get for free with C# and .NET. But sometimes, you need more tools to squeeze out every last drop of performance.

It's also generally very beneficial to learn new languages, which could inspire us to find new ways of solving problems. To specifically do so with a modern language, which could replace C/C++ over time and has a focus on both performance and productivity, could bring a very valuable tool to any developer's toolbox.

Rust has actually been the most loved language every single year, from the 2016 survey, all the way to this year's 2020 survey.

Rust Overview

Rust is a C-style language, similar to C# or C++, and even has influences from C# (among others), with a focus on memory safety and performance.

The slogan on Rust's official website is:

A language empowering everyone to build reliable and efficient software.

The language is statically typed and is primarily imperative but also has functional aspects, similar to C#. It's an open-source language initially developed by Mozilla.

Wikipedia describes the Rust programming language in the following way:

Rust is a multi-paradigm programming language focused on performance and safety, especially safe concurrency. Rust is syntactically similar to C++ but provides memory safety without using garbage collection.

As a C#-developer, you'll find the syntax familiar, with the "Hello World!" for Rust looking like this:

fn main() {
    println!("Hello World!");
}

Rust was announced in 2010, with version 1.0 released in 2015. In comparison, C# was released in the year 2000, Java in 1995, C++ in 1985, and C in 1972. So it's quite a modern language, which has been influenced by many other languages and has hopefully used many lessons learned from these.

Performance

Rust can be as fast as C and C++ and in some cases, it might be even faster. The code compiles to machine code, instead of compiling to an intermediate language (IL), like with C# or being interpreted on the fly, like with JavaScript or Ruby.

The memory management is not provided by using automated garbage collection (like in .NET/Java) or automatic reference counting (like in Swift/Objective C). The memory safety-guarantees are provided by Rust's key concept called Ownership. By enforcing Resource Acquisition Is Initialization (RAII), Rust makes sure that any objects which go out of scope get deconstructed and its resources are freed up.

Systems & Application Programming Language

Systems programming languages typically are more close to the metal and have more direct access to the physical hardware of the machine it is running on, which enables writing performant software, such as operating systems, drivers, embedded systems, game-engines, network services, and more. Assembly language, C, and C++ are examples of traditional systems programming languages.

C# is considered as an application programming language, which usually prioritizes productive ways of building software which gives functionality to end-users. They are usually not intended to compete on performance with systems programming languages.

Rust is a language that tries to straddle both systems and application programming.

Industry Adoption

The 2020 Stack Overflow Developer Survey shows that when it comes to the most professionally used programming language, C# has a 32,3% popularity, while Rust only has 4,8%. Comparing these numbers to JavaScript's 69,7% popularity might indicate that Rust is in an early phase of its widespread professional adoption.

The adoption of Rust does seem to be ramping up though, for good reasons. In a 2020 virtual talk about Rust at Microsoft, one of their cloud developer advocates said:

Rust is the industry’s best chance at safe systems programming

It does seem like Microsoft is exploring gradually switching to Rust from C and C++. These languages are not memory safe, which has caused a lot of costly errors, as mentioned before, with Microsoft's having around 70% of all their security bugs related to memory safety issues.

In 2019, Microsoft experimented with rewriting a low-level component in Windows with Rust, with a reported generally positive experience.

It's said that Amazon Web Services (AWS) uses Rust to power the deployment of the Lambda serverless runtime and some parts of EC2.

Many other companies are adopting Rust, including big players like Facebook (also with Libra), Apple, Google (with Fuchsia), and Cloudflare.

"From C# to Rust"-Series

Given that I'm learning Rust as I'm going, the goals of this series might change over time. But at this time, some topics I aim to cover are:

Fundamentals: Tools and concepts we need to understand
Code basics: Learning the basics of Rust-code and how the concepts relate to C#
Advanced code: Diving deeper into more advanced code and concepts in Rust
Rust specific functionality: Functionality and concepts which exists in Rust, but not in C#
Rust's drawbacks: Exploring what the reasons are behind the perceived steeper learning curve of Rust

There will probably be more subjects discovered along the way. Feel free to write in the comments if there are any specific subjects you're interested in, especially coming in as a C#-developer.

Summary

Some points that make me quite excited about Rust and motivated me to start this exploration are:

Modern C-style language, like C#, should give familiarity
The most loved language for half a decade
Enables both high-level productivity and low-level performance
Growing industry adoption, even by many of the giants

Deno: The Official Node.js-Successor?

Mon, 18 May 2020 12:38:00 GMT

Why is the announcement of Deno 1.0 possibly very exciting? Are there enough upsides to warrant a switch from Node.js to Deno?

The announcement of 1.0 was done middle of May 2020, but the initial announcement came in a presentation named 10 Things I Regret About Node.js by Ryan Dahl in mid-2018.

Deno is not just a rearrangement of the first two and the last two letters of "Node". It's built on top of more than 11 years of experience from Node.js running in production all over the world, by the original creator of Node.js. So this does not seem like another case of "I don't like how this project is handled, so I'm making my own fork", it's a completely new implementation.

10 Regrets about Node.js

The 10 things Ryan Dahl regretted about Node.js, which he acknowledges are impossible to change now, seem to be large motivators for the creation of Deno. It's worth noting that JavaScript has changed a lot during its 11 years of existence and Node has driven a lot of those changes.

The numbered regrets brought up in the talk were:

Not sticking with promises: Promises allow the usage of async/await and avoids "Callback Hell".
Security: Your linter shouldn't get complete access to your computer and network.
The Build System (GYP): Awful experience for users. It's a non-JSON, Python adaptation of JSON.
package.json: Not a strictly necessary abstraction and doesn't exist on the web. Includes all sorts of unnecessary information.
node_modules: Massively complicates the module resolution. Deviates greatly from browser semantics.
require("module") without the extension ".js": Needlessly less explicit. Module loader has to query the file system at multiple locations.
index.js: Needlessly complicated the module loading system.

It was also mentioned that Deno supports the following things:

Unhandled promises should die immediately
Support top-level await
Browser compatible where functionality overlaps

Introducing Deno

Deno is a runtime for both JavaScript and TypeScript, built on the V8 JavaScript engine and Rust, with the asynchronous runtime Tokio.

The feature highlights, as of version 1.0, are:

Secure by default: Access to files, network or environment must be explicitly enabled
Supports TypeScript out of the box
Ships a single executable: No separate package-manager, like npm
Built-in utilities: test runner, code formatter, built in debugger, dependency inspector and more
Bundling: Scripts can be bundled into a single JavaScript file
Standard modules: Audited and guaranteed to work with Deno

Executing JavaScript/TypeScript

Deno being a single executable file, not needing a separate package-manager or package.json-file, an example of a working HTTP server application looks like this:

import { serve } from "https://deno.land/std@0.50.0/http/server.ts";
for await (const req of serve({ port: 8000 })) {
  req.respond({ body: "Hello World\n" });
}

There is no need to install anything beforehand or add any configuration-files. All you need to run is:

deno run example.js

Since the code is executed in a sandbox, which is secure by default, the explicit access must be granted for the fetching the remote dependency, by adding the flag --allow-net to the command-line.

The remote dependency is cached locally and only reloaded if the script is executed with the flag --reload.

Limitations

Deno 1.0 has some known limitations, which include things like:

No automatic compatibility with existing npm-packages
HTTP server performance is not as good as Node.js, even if it's not too far away
TypeScript performance issues

Since Deno uses ECMAScript modules, which uses import instead of require, any module using require has to be converted.

Summary

I'm surprised at how excited I am about the potential of Deno. For me, to have the creator of Node.js use a decade of learning to start over with a blank slate is what makes this a rare situation of high potential.

Some things I look forward to from Deno are:

A fresh take on a JavaScript/TypeScript runtime
First Class TypeScript Support
Skipping package.json and npm install when you just want to get started fast
Promises as default: Avoiding callback hell and mixed concepts between different parts of the code
Not having to deal with the node_modules-folder

C# Nullable Reference Types: IntelliSense Confusion

Thu, 13 Feb 2020 16:49:00 GMT

The feature and concept of Nullable reference types were introduced in C# 8.0 and it basically made all types non-nullable by default and ensured that these types could never be assigned the value null. This is one of my favorite features in C# recently, but there are scenarios where a mixed nullable environment could cause confusion.

To enable the assignment of the value null to a type, you have to explicitly mark that type. This uses the same concept of nullable as introduced in C# 2.0, where you, for example, make an int nullable by adding a question mark after it: int?.

When we look at a regular example service-class, we can see which benefits can be had from Nullable reference types:

public class ProductService
{
    // This method accepts a non-null string for 'productId'
    // and always returns a string
    public string FormatProductId(string productId)
    {
        // ...
    }

    // This method accepts a nullable 'formattedProductId'
    // and returns a string or null
    public string? TryGetProductName(string? formattedProductId)
    {
        // ...
    }
}

This makes things all fine and clear. We know that the method FormatProductId never returns null and that it doesn't accept null in its parameter. We also know that the method TryGetProductName returns a string which could be null and that the parameter accepts a string which could be null.

This is great, this means that we don't have to perform a null-check on productId-parameter of the FormatProductId-method, right? Well, not exactly...

Confusion: Mixed nullable environments

In an environment where all your code has Nullable reference types enabled, you can trust the output of a method and the input to its parameters. In a mixed nullable environment, things are not as straight forward, especially when you look at how IntelliSense in Visual Studio signals what to expect from the code.

Scenario 1: Modern app & legacy library

Imagine that your new modern app has Nullable reference types enabled, but you're using an external library that is legacy and does not have this enabled. This external library can be your own old library or something you've included from NuGet.

The problem now becomes that the external library is signaling, for example, that it has a method that returns a string and not a string?, so you should be able to trust that it is not null, right? Unfortunately not. Even with a local non-nullable project, IntelliSense tells me that the returned string is not null, even when it is.

Scenario 2: Legacy app & modern library

Imagine that you have just put together a nice library that you want others to use, either in your project, organization or publicly through NuGet. One of the best parts about using Nullable reference types is that the compiler will warn you if you try to send in a null value as a parameter to a method that explicitly states that it doesn't support null.

Nice, now you can clean out all those noisy null-checks at the top of all the methods, right? Unfortunately not. Your code might be used by another assembly (or an older version of Visual Studio), which doesn't detect the non-nullability.

In a way, this means you have to reverse the way you do null-checks in your code.

public class ProductService
{
    // This method does not accept a null-value
    // and if it does, it should throw an exception
    public string FormatProductId(string productId)
    {
        if (productId == null)
            throw new ArgumentNullException(productId);
        // ...
    }

    // This method accepts null-values
    // and should adjust its logic accordingly
    public string? TryGetProductName(string? formattedProductId)
    {
        return
            formattedProductId != null
            ? GetProductName(formattedProductId)
            : null;
    }
}

Key takeaways

My own take-aways from exploring this aspect of Nullable reference types are:

When building a library, always check for null in incoming method-arguments, even when Nullable reference types is enabled
When consuming an external legacy library, don't trust the return-type to not be null (even if it says it's not)
In a mixed nullable environment, the feature to guard us against NullReferenceExceptions is likely to mistakenly cause some more of them
When this feature is fully adopted, there will be a reduction in a lot of the overhead in null-handling code

Thoughts

Hopefully, in .NET 5, this feature is enabled by default and these kinds of confusions, and described associated errors can be avoided.

One idea for an improvement to the IntelliSense-behavior around assemblies that are not known to have Nullable reference types enabled could be to show all these types as nullable. Both because it makes things super-clear, but also because of the fact that they actually are nullable.

This change would make everything in the whole .NET Core CLR light up as nullable, but as of .NET Core 3.1, it all is nullable, by definition.

PowerShell LINQ with Short Aliases

Mon, 15 Jul 2019 17:04:00 GMT

Most modern applications or code today deal with some kind of filtering or querying. In C# and .NET, we have Language Integrated Query (LINQ), which we also have access to in PowerShell, because it's built on .NET.

To list the top 10 largest files in the Windows temporary folder, which is larger than 1 Mb and starts with the letter W, skipping the first 5, ordering by size, the C#-code with LINQ would look somewhat like this:

new System.IO.DirectoryInfo(@"C:\Windows\Temp")
    .GetFiles()
    .Where(x => x.Length > 1024 && x.Name.StartsWith("W"))
    .OrderByDescending(x => x.Length)
    .Select(x => new { x.Name, x.Length })
    .Skip(5)
    .Take(10)
    .ToList()
    .ForEach(x => Console.WriteLine($"{x.Name} ({x.Length})"));

The equivalent logic in PowerShell has a bit of a more daunting syntax, especially if you're not used to it:

Get-ChildItem "C:\Windows\Temp" `
| Where-Object {$_.Length -gt 1024 -and $_.Name.StartsWith("W")} `
| Sort-Object {$_.Length} -Descending `
| Select-Object -Property Name, Length -First 10 -Skip 5 `
| ForEach-Object {Write-Host "$($_.Name) ($($_.Length))"}

That's a bit explicit and verbose, but if you use the command Get-Alias in PowerShell, you will see a lot of useful aliases, which make the syntax a bit terser and easier to get an overview of:

gci "C:\Windows\Temp" `
| ?{$_.Length -gt 1024 -and $_.Name.StartsWith("W")} `
| sort{$_.Length} -Descending `
| select Name, Length -First 10 -Skip 5 `
| %{write "$($_.Name) ($($_.Length))"}

In a real scenario, you probably wouldn't write each result to the console, but let PowerShell present the result in its default grid format.

HTML Encode TagHelper in ASP.NET Core

Thu, 27 Jun 2019 14:31:00 GMT

For a specific scenario recently, I wanted to display the HTML-encoded output of a TagHelper in ASP.NET Core. So I wanted to use the TagHelper, but not output its actual result, but see the raw HTML which would have been included in my template.

So I created another TagHelper, which allows me to wrap any HTML, inline code in ASP.NET Core and other TagHelpers, and get all the content inside the TagHelper's tag to be HTML-encoded, like this:

<html-encode>
    <a href="@Url.Action("Index")">Read More</a>
    @Html.TextBox("No_Longer_Recommended-TagHelpers_Preferred")
    <my-other-tag-helper />
</html-encode>

From this, I will get the raw HTML of the link with an UrlHelper-result, the result of the HTML-helper and the result of my other TagHelper.

The source-code for the html-encode-TagHelper is as follows:

[HtmlTargetElement("html-encode", TagStructure = TagStructure.NormalOrSelfClosing)]
public class HtmlEncodeTagHelper : TagHelper
{
    public override async Task ProcessAsync(TagHelperContext context, TagHelperOutput output)
    {
        var childContent = output.Content.IsModified
            ? output.Content.GetContent()
            : (await output.GetChildContentAsync()).GetContent();

        string encodedChildContent = WebUtility.HtmlEncode(childContent ?? string.Empty);

        output.TagName = null;
        output.Content.SetHtmlContent(encodedChildContent);
    }
}