This is a modern .NET companion to my original post about C# DateTime to RFC3339/ISO 8601.

Date and time become harder to work with as soon as a timestamp leaves your single-language application. In JSON, query strings, headers, logs, and file names, it becomes text or a number that another system has to interpret correctly.

In this article, we'll go through the practical formats for services, TypeScript/JavaScript frontends, logs, and files. For each one, we'll look at how to produce it from a DateTimeOffset and what survives when you parse it back.

In modern .NET code, use DateTimeOffset for timestamps. Unlike DateTime, it stores both the clock time and its UTC offset, which is the information most easily lost at a service boundary.

Every example below formats and parses the same timestamp, a summer afternoon in Central European Summer Time:

var timestamp = new DateTimeOffset(
    year: 2026, month: 7, day: 14,
    hour: 9, minute: 11, second: 30, millisecond: 123,
    offset: TimeSpan.FromHours(2));

DateTimeOffset Formats at a Glance

This overview shows what each format preserves when parsed back:

One of the first four rows is almost always the right answer for an API. Of the .NET standard specifiers, O preserves the offset and all seven fractional digits, R is useful for HTTP headers, s drops the offset, and u converts to UTC. The remaining formats deliberately discard information, which is useful when you intend it, but it's a bug when you don't.

UTC (Coordinated Universal Time) is the global reference time represented by the zero offset +00:00, often written as Z. Converting a timestamp to UTC preserves the exact instant and its available fractional precision in one unambiguous value, which makes it a reliable choice for storage and exchange between systems.

Format a DateTimeOffset as ISO 8601 and RFC 3339

ISO 8601 is a large standard that covers dates, times, UTC, local time with an offset, durations, intervals, and more. It's broad enough that "we use ISO 8601" isn't really a contract on its own. For timestamps exchanged between applications, RFC 3339 defines a much narrower profile of it, and that profile is what most APIs mean when they say ISO 8601.

If you have no other requirement, an RFC 3339 timestamp with an explicit offset is the format to send. It's unambiguous, and almost every language and framework can parse it. RFC 3339 timestamps also sort chronologically as text when they use the same offset representation and the same number of fractional digits.

Use one format for an explicit offset and another when the contract requires UTC with Z:

const string offsetFormat = "yyyy-MM-dd'T'HH:mm:ss.fffK";
const string utcFormat = "yyyy-MM-dd'T'HH:mm:ss.fff'Z'";

var withOffset = timestamp.ToString(offsetFormat, CultureInfo.InvariantCulture);
// 2026-07-14T09:11:30.123+02:00

var inUtc = timestamp.ToUniversalTime().ToString(utcFormat, CultureInfo.InvariantCulture);
// 2026-07-14T07:11:30.123Z

Lowercase fff requires exactly three fractional digits. Use FFFFFFF instead when trailing zeros and the decimal point may be omitted. For a DateTimeOffset, the K token is equivalent to zzz: both write the numeric offset, including +00:00 for UTC.

Only append Z after converting the clock time to UTC. Adding it directly to the example's 09:11:30 moves the timestamp two hours into the future without raising an error.

The offset format parses directly. Since the Z in utcFormat is a literal, the UTC format needs explicit parsing styles:

var utcStyles = DateTimeStyles.AssumeUniversal | DateTimeStyles.AdjustToUniversal;

var parsedOffset = DateTimeOffset.ParseExact(
    withOffset, offsetFormat, CultureInfo.InvariantCulture, DateTimeStyles.None);
// 2026-07-14T09:11:30.1230000+02:00

var parsedUtc = DateTimeOffset.ParseExact(
    inUtc, utcFormat, CultureInfo.InvariantCulture, utcStyles);
// 2026-07-14T07:11:30.1230000+00:00

The offset says how far the clock was from UTC, not which time zone it was in. If the receiver needs the zone itself, send the IANA time zone ID separately. The DateTimeStyles documentation covers the UTC parsing flags used again below.

In the Basic Format for File Names and Logs

ISO 8601 also has a basic format without separators, which works where : isn't allowed or is inconvenient, such as file names, log identifiers, cache keys, and exported data. Fixed-width UTC values sort chronologically as plain text, which is often the real reason to use them:

const string fileFormat = "yyyyMMdd'T'HHmmss.fff'Z'";

var fileTimestamp = timestamp
    .ToUniversalTime()
    .ToString(fileFormat, CultureInfo.InvariantCulture);
// 20260714T071130.123Z

DateTimeOffset.ParseExact(fileTimestamp, fileFormat, CultureInfo.InvariantCulture, utcStyles);
// 2026-07-14T07:11:30.1230000+00:00

DateTimeOffset.Parse doesn't accept this basic format, and it has no format parameter. Use DateTimeOffset.ParseExact with fileFormat and keep the format string next to the code that reads these values back. Keep the field widths and the UTC suffix consistent if you rely on alphabetical sorting, since a single variable-width field breaks the ordering for every file in the directory.

DateTimeOffset in JSON and TypeScript/JavaScript

When a DateTimeOffset is part of a JSON request or response, you usually shouldn't call ToString at all. System.Text.Json reads and writes the extended ISO 8601 profile by default, which is also valid RFC 3339, and it's what ASP.NET Core uses for minimal APIs and controllers out of the box:

var json = JsonSerializer.Serialize(timestamp);
// "2026-07-14T09:11:30.123+02:00"

var parsed = JsonSerializer.Deserialize<DateTimeOffset>(json);
// 2026-07-14T09:11:30.1230000+02:00

The default output trims trailing zeros, so it writes a timestamp with whole seconds as 2026-07-14T09:11:30+02:00. System.Text.Json writes a DateTimeOffset in UTC with +00:00, but a DateTime with DateTimeKind.Utc with Z:

JsonSerializer.Serialize(timestamp.ToUniversalTime()); // "...T07:11:30.123+00:00"
JsonSerializer.Serialize(timestamp.UtcDateTime);       // "...T07:11:30.123Z"

Both are correct RFC 3339 and both parse the same way in .NET and in TypeScript/JavaScript. It only becomes a problem when something on the other side compares timestamp strings for equality, or when a test asserts on the exact text.

If the API contract requires UTC with Z and a fixed precision, add a converter once instead of formatting values by hand throughout the application:

public sealed class UtcDateTimeOffsetJsonConverter : JsonConverter<DateTimeOffset>
{
    private const string Format = "yyyy-MM-dd'T'HH:mm:ss.fff'Z'";

    public override DateTimeOffset Read(
        ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        return DateTimeOffset.ParseExact(
            reader.GetString()!,
            Format,
            CultureInfo.InvariantCulture,
            DateTimeStyles.AssumeUniversal | DateTimeStyles.AdjustToUniversal);
    }

    public override void Write(
        Utf8JsonWriter writer, DateTimeOffset value, JsonSerializerOptions options)
    {
        writer.WriteStringValue(
            value.ToUniversalTime().ToString(Format, CultureInfo.InvariantCulture));
    }
}

Because Read uses ParseExact, this converter accepts only UTC timestamps that end in Z and contain exactly three fractional digits. The default System.Text.Json DateTimeOffset format uses variable fractional precision and writes UTC as +00:00, so every client has to follow this custom contract too.

Register it once with options.Converters.Add(new UtcDateTimeOffsetJsonConverter()). Let the serializer own the wire format, and let a custom converter own any deviation from it.

Read the Value in TypeScript/JavaScript

A browser can read either the default JSON string or Unix milliseconds as the same instant:

const fromText = new Date("2026-07-14T09:11:30.123+02:00");
const fromUnix = new Date(1784013090123);

console.log(fromText.toISOString());                    // 2026-07-14T07:11:30.123Z
console.log(fromText.getTime());                        // 1784013090123
console.log(fromText.getTime() === fromUnix.getTime()); // true

A TypeScript/JavaScript Date stores milliseconds since the epoch, so it uses +02:00 to find the instant and then discards the offset. JSON.stringify writes the result in UTC with Z. If the frontend needs the sender's original offset, send it separately.

There are three traps worth knowing about at this boundary:

• A date and time without an offset is read as the browser's local time. new Date("2026-07-14T09:11:30") means something different for every visitor, which is exactly what the s format produces.
• A date-only string is read as UTC instead. new Date("2026-07-14") is midnight UTC, so the same string is inconsistent with the rule above. This is the classic reason a date shows up as the day before for users west of UTC.
• Unix seconds passed straight to new Date land in January 1970. new Date(1784013090) is 1970-01-21T15:33:33.090Z, because the constructor expects milliseconds.

The ECMAScript Date Time String Format defines exactly three fractional digits. The seven digits produced by O therefore rely on engine-specific fallback parsing. Keep O for .NET-to-.NET text rather than a browser-facing wire format.

Convert a DateTimeOffset to and From Unix Time

Unix time, also called epoch time, counts from 1970-01-01T00:00:00Z and is useful when a contract expects a number. DateTimeOffset has built-in Unix time support in both directions:

var seconds = timestamp.ToUnixTimeSeconds();           // 1784013090
var milliseconds = timestamp.ToUnixTimeMilliseconds(); // 1784013090123

DateTimeOffset.FromUnixTimeSeconds(seconds);
// 2026-07-14T07:11:30.0000000+00:00

DateTimeOffset.FromUnixTimeMilliseconds(milliseconds);
// 2026-07-14T07:11:30.1230000+00:00

The original offset is gone when the value comes back as UTC. Seconds discard the fractional second, while milliseconds discard any finer 100-nanosecond ticks. Agree on the unit, because reading seconds as milliseconds produces a date in January 1970 rather than an error. JWT claims use seconds, while JavaScript Date uses milliseconds.

Calendar Values and Display

Sometimes the value is not a timestamp. Use DateOnly for birthdays and billing days, and TimeOnly for opening times and daily alarms:

var dateAtOffset = DateOnly.FromDateTime(timestamp.DateTime);    // 2026-07-14
var timeAtOffset = TimeOnly.FromDateTime(timestamp.DateTime);    // 09:11:30.123
JsonSerializer.Serialize(dateAtOffset); // "2026-07-14"
JsonSerializer.Serialize(timeAtOffset); // "09:11:30.1230000"

For display, standard formats such as d and F use the supplied CultureInfo:

var culture = CultureInfo.GetCultureInfo("sv-SE");

timestamp.ToString("d", culture); // 2026-07-14
timestamp.ToString("F", culture); // tisdag 14 juli 2026 09:11:30

Choose the relevant offset before extracting a calendar value, and keep display text as output only. A date near midnight may differ between the original offset and UTC. Culture changes the representation, not the time zone, which is a separate conversion using TimeZoneInfo. For a browser-side example using older tools, see Display Local DateTime with Moment.js in ASP.NET.

Parse Input Strings Exactly

When an API accepts more than one representation, TryParseExact validates the input against an array of formats and rejects everything else:

string[] acceptedFormats =
{
    "O",
    "yyyy-MM-dd'T'HH:mm:ss.fffK",
    "yyyy-MM-dd'T'HH:mm:ss.FFFFFFFK"
};

if (DateTimeOffset.TryParseExact(
    input, acceptedFormats, CultureInfo.InvariantCulture, DateTimeStyles.None, out var parsed))
{
    // 2026-07-14T09:11:30.1230000+02:00
}

The more flexible DateTimeOffset.TryParse handles a much wider range of input, which is convenient until it accepts something you did not intend. When the input has no offset, TryParse fills in the offset of the machine that runs it, so the same request parses differently on a developer's laptop and on a server in another region. Pass DateTimeStyles.AssumeUniversal when a missing offset must mean UTC, and use TryParseExact when the accepted formats are part of the contract.

Summary

Keep timestamps as DateTimeOffset inside the application and database, and format them only at system boundaries. SQL Server has a native datetimeoffset type, while strings lose validation, date arithmetic, and reliable sorting across offsets.

• Text APIs and frontends: use the System.Text.Json default, or a documented RFC 3339 contract. Keep O for .NET-to-.NET text that needs all seven fractional digits.
• Numeric contracts: use Unix time and agree on seconds or milliseconds.
• Files and display: use fixed-width UTC for sortable names, and localized text produced from the typed timestamp for people.

Pick a format based on the offset and precision it preserves, parse the same format you write, and supply any missing offset explicitly. A wrong timestamp is still valid, which is why these mistakes rarely raise an error.

For the original DateTime and .NET Framework implementation, see the original article.

Clear boundaries help you stay in control, avoid obvious bugs, and make larger changes with more confidence. This matters even more when AI can make broad changes under the hood. You still need to preserve the functionality that the rest of the application relies on.

Although the examples use TypeScript, the same ideas work for JavaScript. Workspaces, package exports, barrel files, and the Biome and ESLint rules are not TypeScript-only. The TypeScript-only parts are project references, declaration output, and type-aware ESLint configuration.

In this article, we'll look at package exports in a monorepo and lint rules for a single codebase.

Packages And Workspaces

The usual way to create a stronger boundary is to split a monorepo into packages. Each package has its own package.json, build output, and public entry points. Other packages then depend on it by name instead of reaching into its source tree.

pnpm workspaces find and link the packages locally. They do not decide which files are public, though:

# pnpm-workspace.yaml
packages:
  - apps/*
  - packages/*

The package's exports map says what other packages are allowed to import:

// packages/orders/package.json
{
  "name": "@acme/orders",
  "private": true,
  "types": "./dist/index.d.ts",
  "exports": "./dist/index.js"
}

The source entry point lists the symbols that belong to that public API:

// packages/orders/src/index.ts
export { createOrder } from "./create-order.js";
export type { Order, OrderTotals } from "./types.js";

The consuming app can import createOrder from @acme/orders, but this deep import is not part of the public API:

import { calculateTotals } from "@acme/orders/calculate-totals";

With a module resolution mode that understands package exports, TypeScript rejects the deep import because that subpath was never exported. It's worth noting that a path alias or relative import into another package's src directory can still bypass this, so teams usually lint against cross-package source imports too.

That is the important distinction: the workspace links packages together, while the exports map controls which package paths consumers can use. TypeScript project references help with build ordering and keep the projects separate:

// packages/orders/tsconfig.json
{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "outDir": "dist",
    "rootDir": "src"
  },
  "include": ["src"]
}

Project references are TypeScript-specific. You can read more in TypeScript's project references documentation and Node's exports documentation.

When Everything Is One Codebase

Packages are useful when a repository already has clear package-sized parts. They are more ceremony than many applications need, though. If everything lives under one src directory, there is no package boundary between orders and checkout:

src/
├── features/
│   ├── orders/
│   └── checkout/
└── app/

An export is still importable from any file that can resolve its path. Path aliases make imports nicer, but they do not make folders private. In a single codebase, you need a convention and a lint rule to stop people bypassing public entry points.

Barrel Files As A Convention

A barrel file is usually an index.ts file that re-exports the symbols meant for use outside a folder:

// src/features/orders/index.ts
export { createOrder } from "./create-order";
export { getOrderSummary } from "./order-summary";

Code elsewhere imports from @/features/orders, while internal helpers stay out of the barrel. Without linting, someone can still import them directly:

import { calculateTotals } from "@/features/orders/calculate-totals";

Enforcing Barrel Imports

ESLint's import/no-internal-modules rule can reject submodule imports while still allowing the folder entry point:

{
  "rules": {
    "import/no-internal-modules": [
      "error",
      { "forbid": ["@/features/*/*"] }
    ]
  }
}

The exact pattern depends on your aliases. For larger architectures, eslint-plugin-boundaries can define which entry points different kinds of folders may use.

Biome does not require barrel imports. Its noBarrelFile rule does the opposite and reports files that re-export other modules.

The Limits Of Barrel Files

Barrel files are useful documentation, but they also have a few problems:

• They are only a convention without linting. An index.ts file is not a visibility boundary, so deep imports are still possible.
• They can make the dependency graph bigger. Re-exporting runtime modules can load or analyze more modules than the consumer needs. This is the reason Biome provides noBarrelFile.
• They can run top-level side effects. A runtime re-export adds its target module to the import graph. When the barrel is loaded, that module may be instantiated and evaluated even if the caller needs a different export. Top-level work such as registering a handler, changing global state, reading environment state, or logging can then run unexpectedly. Bundlers may remove unused modules when static analysis and side-effect metadata allow it, but tree-shaking is not a replacement for side-effect-free modules.
• They can hide ownership and create cycles. A large index.ts becomes another API manifest, and importing back through it from an internal file can introduce a cycle.

If you want smaller module graphs and clearer ownership, Biome's no-barrel approach is a good alternative.

No Barrels With Biome

Enable noBarrelFile together with noPrivateImports:

{
  "linter": {
    "rules": {
      "correctness": {
        "noPrivateImports": "error"
      },
      "performance": {
        "noBarrelFile": "error"
      }
    }
  }
}

Now you can import files directly, while visibility is declared on their exports:

// src/features/orders/create-order.ts

/** @public */
export function createOrder() {
  return calculateTotals();
}

/** @package */
export function calculateTotals() {
  // ...
}

Biome recognizes @public, @package, and @private, along with the equivalent @access values. Package visibility allows imports from the same folder and its subfolders. Private exports are normally limited to the same module. index.ts and mod.ts files get special handling so their submodules can use private exports.

Code inside src/features/orders can use calculateTotals, while code in src/features/checkout gets a lint error if it imports it.

Flipping The Default Is Not Available

It would be convenient to make every export package-private and add @public only to the intended API. Biome does not provide that setting. Untagged exports are public, and there is no supported defaultVisibility option.

Mark internal exports with @package or @private, and leave public exports untagged or mark them with @public. noPrivateImports checks static imports, but not dynamic import() or CommonJS require() calls. It also ignores resources and dependencies under node_modules.

The ESLint Alternative

With ESLint, eslint-plugin-import-access provides a similar JSDoc-based model for typed configurations. It supports @package, @private, and @public, and includes a TypeScript language-service plugin that can keep restricted exports out of auto-completion.

For broader architecture rules, eslint-plugin-boundaries can classify folders and control which parts of the codebase may import from each other.

Faster Feedback In VS Code

The command line and CI remain the final authority, but editor extensions can show boundary violations while you work instead of making you wait for a build or full lint run.

Install the official Biome extension with @biomejs/biome, or the Microsoft ESLint extension with the ESLint plugins used by your project:

pnpm add -D @biomejs/biome eslint eslint-plugin-import

If you use eslint-plugin-import-access, add it with typescript and typescript-eslint as required by your ESLint configuration. The extensions provide inline diagnostics and quick fixes:

// .vscode/settings.json
{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.biome": "explicit",
    "source.fixAll.eslint": "explicit"
  },
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ]
}

Choose one tool to own formatting and let the other focus on lint diagnostics. An invalid import shows up in the editor instead of surprising you after the build or CI lint step.

Summary

In a monorepo, pnpm workspaces connect packages, project references describe the TypeScript build graph, and package exports define the public paths. In a single codebase, barrels are a convention that ESLint can enforce, while Biome can ban them and enforce visibility on individual exports.

Biome keeps untagged exports public, so internal exports must be annotated explicitly.

The same guidance applies to JavaScript. Only the project references, declaration output, and typed-linting parts require TypeScript.

You want to get the right piece of knowledge into the AI coding agent at the right time. If done incorrectly, you could bring in too many tokens of data for every message, for the rest of the session. Or the agent doesn't see it until it has already gone down the wrong path. Both kinds of mistakes lead to the same results: worse outcomes, higher costs, and more iterations of corrections.

In this article, we'll go through the four layers of instructions, what triggers each of them to load, and how to pick the right layer for the right kind of knowledge. The layers exist in Codex, Claude Code, Cursor, Gemini CLI, GitHub Copilot, and most similar tools, even if the file names differ between them.

Understanding the Different Layers

It helps to stop thinking of context as one big bucket, and instead think of it as separate delivery mechanisms:

Every mechanism you'll recognize from these tools falls into one of these buckets. Once you can place a piece of knowledge in the right bucket, deciding where it belongs stops being guesswork.

Always-Loaded Instructions

This is the layer most people already know: AGENTS.md, the open format used by Codex, GitHub Copilot, and many other tools, CLAUDE.md in Claude Code, and GEMINI.md in Gemini CLI. These files are read automatically at the start of every session, before the agent does anything else.

If your repository already has an AGENTS.md, the CLAUDE.md file can simply contain the text @AGENTS.md to automatically import it, so you don't have to maintain two copies.

The automatic loading is exactly what makes this layer expensive. A ten-line instruction file costs you ten lines, once. A three-hundred-line instruction file costs you three hundred lines on every single message of the session, even when the current task needs none of it. There is no opt-out and no "only when relevant" for this layer.

This is why keeping this layer short matters so much. Put the things here that the agent genuinely can't figure out on its own: the exact test command, the package manager, the files it must never touch, and the safety rules that apply every time. Almost everything else can live in one of the cheaper layers below.

This is also a good layer to keep instructions on where the agent can look for more information when needed, for on-demand reads or progressive disclosure. For example, stating the path where documentation files are located, where to read previous ADRs, code style guidelines or similar, so the agent doesn't have to scan multiple directories for it and waste context.

On-Demand Reads

README.md, type definitions, existing tests, the component you tell the agent to "follow the pattern of". None of this loads automatically. The agent has to decide to read the file, spend a tool call doing it, and the content then stays in the context for the rest of the session (or until it gets compacted away).

When used well, this is a good deal. You don't pay for anything that isn't relevant to the current task, and the files can carry far more detail than you would ever want in an always-loaded file. The trade-off is that the agent has to make the right call about what to read.

Point the agent to the right file, and you get one cheap, targeted read. Leave it vague, and the agent might read five files to find the one that mattered, or miss it completely.

It's worth noting that some tools can scope instructions to a part of the repository, like .claude/rules/-files with paths: in their frontmatter, Copilot's .instructions.md files with applyTo globs, or nested AGENTS.md files deeper down in the folder structure. These sit right between always-loaded and on-demand: they don't load for every session, but they load automatically as soon as the agent touches a matching file. This is a useful middle ground for conventions that only matter in one part of a codebase, for example, in a monorepo.

Progressive Disclosure

This is the layer that's easiest to underestimate, and the one that makes the other layers scale.

Skills and plugins are the clearest example. The agent doesn't load the full instructions of every skill up front, since that would defeat the whole point. What it always loads is a short index: a name and a one-line description for each available skill. The full content is only pulled into the context when a skill is actually invoked. The agent knows that the capability exists, without having paid for reading all of it, until it's actually needed.

Anthropic's post about Agent Skills calls this principle progressive disclosure, and it's a good name for the whole layer.

MCP tools show why this layer matters, because they traditionally haven't used it. When you connect an MCP server, the client typically loads every tool's name, description, and full parameter schema up front, straight into the always-loaded layer. This is why adding too many MCP servers is a well-known problem: Anthropic measured a typical five MCP-server setup at around 55,000 tokens of tool definitions, before the agent has even done any work.

The fix is moving the definitions into this layer. With deferred tool definitions, supported by both Anthropic's and OpenAI's platforms, only an index of names stays loaded, and a full schema only arrives when that specific tool is searched for or used. Claude Code and Codex both made this the default in mid-2026, but with fallbacks to up-front loading for older models and providers, so it's still worth checking how your tool of choice handles it.

You can build the same pattern yourself, with nothing more than Markdown files. Keep a short index in an always-loaded file, like AGENTS.md, where each line describes a subject and points to the file holding the details. The pointer instructions mentioned in the always-loaded layer are exactly this: the index costs one line per subject on every message, while a linked file only enters the context when a task actually needs it. These file pointers can be used recursively through folders and files.

Claude Code's auto memory is a built-in example of the pattern. The agent writes down its own learnings in topic files and maintains a MEMORY.md file as a concise index of what's stored where. The index is loaded at the start of every session, while the topic files are only read on demand, when something in the index matches the task at hand.

Anything that is occasionally useful, expensive to load, and possible to identify with a short label is a candidate for this layer. This is the argument for moving long, situational workflows out of AGENTS.md and into skills: a one-line pointer costs almost nothing, and the full content only loads when it's actually relevant.

Live Lookups

The last layer isn't really context in the usual sense. It's a request-response cycle in the middle of a task: nothing is preloaded, a lookup goes out when it's needed, and only the answer comes back. Anthropic's article about context engineering calls this strategy just-in-time context: the agent holds lightweight references, like file paths and URLs, and fetches the actual data at runtime.

The most common form isn't MCP servers or web fetches, it's plain CLI commands. git log and git diff answer history questions without a single file being read into the context. The gh CLI turns pull requests, issues, and CI runs into one-line lookups. A jq filter returns the one field the agent asked about, instead of the whole JSON file. The shape of the command decides the shape, and the size, of the answer, which is what makes the terminal such a strong context tool for agents.

The same mechanism covers MCP calls to a database, documentation lookups, and web fetches. The context is not filled up until the moment of use, and the answer is current, even when the underlying data has changed since yesterday. Asking a documentation tool for the signature of one specific function costs a fraction of pasting in an entire API reference. The catch is that live lookups only work well when they're specific. A vague query returns a vague and bloated answer, and you're back to the same problem as pasting in a whole file.

A Concrete Example

Let's take one concrete instruction, straight from the AGENTS.md of this website: "run pnpm run format after code changes". Where it belongs depends completely on how often it's needed:

• If it applies to every change in the repository, it belongs in AGENTS.md/CLAUDE.md. It's short, it's universal, and the always-loaded cost is worth it.
• If it only applies to one part of the repository, with its own formatting rules, it belongs in a path-scoped rule or a nested instruction file, not in the root file.
• If it's one step of a larger, occasional workflow, like a release checklist, it belongs in a skill that only loads when that workflow runs.
• If the right command depends on what was changed, it's not really a standing instruction at all. It's something the agent should look up in package.json on demand, instead of something you hardcode anywhere.

The same fact, four possible homes, and four very different costs depending on which one you pick.

Picking the Right Layer

There is no right or wrong when it comes to picking a layer, but asking three questions will settle most cases:

• How often is it needed? Knowledge that's needed on every message belongs in the always-loaded layer, if you can keep it short. Knowledge that's needed occasionally belongs in a layer that only loads when it's relevant.
• Is it durable, or about the current task? Durable conventions belong in files. Current-task specifics belong in the prompt, or in a scratch file the agent reads once.
• Would a lookup be cheaper than a preload? If the agent can find the answer itself with one targeted read or one query, that's usually cheaper than a standing instruction, and it stays correct when the underlying thing changes.

These questions won't give a universally right answer, but they're a good check of your instincts before you add one more paragraph to a file that will reload on every message for the rest of the project's life.

More Than a Cost Problem

It's tempting to treat all of this purely as cost optimization, but the quality effect is at least as important.

A short, focused always-loaded layer keeps the agent's attention on the few rules that apply every time, which makes it follow them more reliably. This effect is real enough that Claude Code's documentation recommends keeping instruction files under 200 lines, since longer files reduce how reliably the instructions get followed.

The other layers contribute in the same direction. Well-placed pointers and indexes let the agent start from the right assumptions and go straight to the relevant files, so its effort goes into the actual task. The first attempt is more often the right one, and the follow-up corrections become fewer. Overloading or starving the layers produces the reverse, in both quality and cost.

Getting the layering right improves quality and cost at the same time, because both depend on the same thing: the right information arriving at the right time, in the right shape.

Summary

Instructions to an AI coding agent don't travel through one single pipe. They arrive as always-loaded files, on-demand reads, progressively disclosed indexes, and live lookups, where each layer has a different trigger and a different cost.

The skill worth building is not writing a longer AGENTS.md. It's recognizing which layer a piece of knowledge actually belongs in, and trusting the other layers to do their job. Keep the root file short, move the occasional workflows into skills, and let the agent look up the rest.

This is the ASP.NET Core companion to my original post on NullableGuidConstraint for ASP.NET MVC & WebApi.

The original article implements one constraint for both traditional ASP.NET MVC and Web API. ASP.NET Core unified those programming models and includes a built-in guid route constraint, so the custom compatibility constraint is no longer needed in modern applications.

Optional nullable GUID parameters

Combine the built-in guid constraint with the optional-route marker:

[HttpGet("customers/{id:guid?}")]
public IActionResult Get(Guid? id)
{
    return id is null
        ? Ok("Return all customers")
        : Ok($"Return customer {id}");
}

This route matches both:

/customers
/customers/0f8fad5b-d9cb-469f-a165-70867728950e

It does not match a non-GUID value such as:

/customers/not-a-guid

Required GUID parameters

Remove ? when the route requires a GUID:

[HttpGet("customers/{id:guid}")]
public IActionResult Get(Guid id)
{
    return Ok($"Return customer {id}");
}

Minimal APIs

The same constraint syntax works with minimal API route handlers:

app.MapGet("/customers/{id:guid?}", (Guid? id) =>
{
    return id is null
        ? Results.Ok("Return all customers")
        : Results.Ok($"Return customer {id}");
});

Constraint versus validation

Route constraints help endpoint selection. They are not a replacement for validating business rules.

Use {id:guid} when a non-GUID path should not select the endpoint. Validate rules such as whether the GUID exists, is allowed, or must not be Guid.Empty inside the endpoint or application layer.

For traditional ASP.NET MVC and Web API, including the shared custom NullableGuidConstraint, see the original article.

This is the modern ASP.NET Core update of my original ASP.NET Request Paths Reference.

That older reference remains useful for applications built on traditional ASP.NET and System.Web. A separate article is needed because ASP.NET Core replaced those request APIs, separates URL components differently, and commonly runs behind reverse proxies or under a configured base path.

Consider this request:

https://www.example.com/MyApplication/MyFolder/MyPage?key=value

In this example, /MyApplication is the application's configured base path. ASP.NET Core exposes that prefix as Request.PathBase, and exposes the remaining path inside the application as Request.Path.

PathBase is not automatically the first URL segment. It is a configured or forwarded path prefix for the application. It is often empty when the app runs at the domain root, such as https://www.example.com/. It can also contain one or more segments, such as /MyApplication or /apps/customers, when the app runs under that URL prefix.

Request path properties

In a controller, Razor Page, middleware, or endpoint, use properties from HttpRequest:

PathBase contains the path prefix that has been separated from the request path. Path contains the remaining request path used by routing inside the application.

For example, if the incoming URL path is /MyApplication/MyFolder/MyPage:

The split can come from middleware such as UsePathBase, hosting under a sub-application, or forwarded proxy configuration such as X-Forwarded-Prefix.

var request = HttpContext.Request;

var pathWithinApplication = request.Path;
var fullPath = request.PathBase + request.Path + request.QueryString;

For the example request:

pathWithinApplication = /MyFolder/MyPage
fullPath              = /MyApplication/MyFolder/MyPage?key=value

Build the absolute request URL

ASP.NET Core deliberately keeps URL components separate. To create the absolute display URL, use GetDisplayUrl() from Microsoft.AspNetCore.Http.Extensions:

using Microsoft.AspNetCore.Http.Extensions;

var absoluteUrl = Request.GetDisplayUrl();
// https://www.example.com/MyApplication/MyFolder/MyPage?key=value

When the application runs behind a reverse proxy, configure forwarded headers so Scheme, Host, and the generated absolute URL reflect the original client request.

Generate application links

Do not manually concatenate paths when generating links to endpoints. Use ASP.NET Core link generation with Url.Action:

var path = Url.Action("Details", "Customers", new { id = 42 });
var absolute = Url.Action(
    "Details",
    "Customers",
    new { id = 42 },
    protocol: Request.Scheme);

For endpoint routing outside a controller, inject LinkGenerator.

Which property should you use?

• Use Request.Path to inspect the route path inside the application.
• Use Request.PathBase + Request.Path when the mounted base path matters.
• Use Request.Query to read parsed query-string values.
• Use GetDisplayUrl() when you need the complete incoming URL for diagnostics or display.
• Use Url, LinkGenerator, or endpoint names when generating application links.

For traditional ASP.NET APIs such as Request.RawUrl, Request.ApplicationPath, and Request.Url, see the original ASP.NET Request Paths Reference.

It worked, but maintaining it had become unnecessarily complicated for what the website needed to be. For example, setting up the frontend pipeline for a small tweak, sometimes several years and major npm package versions later, was an unbelievable waste of time.

Most of the website consists of content: blog posts, conference talks, articles, podcast appearances, and information about me. It did not need a database-backed application with over-complicated architecture and exaggerated technical solutions. I wanted a modern website that was easier to change, faster to experiment with, and better suited for working on together with AI coding agents.

Why Next.js

It's quite clear that React has sort of won the frontend race. I used to think the React model was too simple and stupid, but after using it for a while, I realized that this was actually the strength of the framework. It ensured a data flow which was easy to follow and troubleshoot.

Also, I wanted a website which was rendered on the server, for SEO and predictability, but still allowed the full frontend expressiveness of TypeScript/JavaScript. React has, by far, the largest ecosystem for components and functionality out there. AI coding agents are extremely competent in React and very good at Next.js. Personally, I'm also quite comfortable in Next.js, all the way from Next.js 13 and forward. All that put together made the decision easy for me.

AI-Powered Migration

The migration was done in mid-2026, so it was of course done in collaboration with AI-powered tools, such as AI coding agents.

Deleting the source code for the previous ASP.NET solution in the repository deleted more than 9 000 lines of code across 118 files. That included various code, templates, scripts, libraries, configuration, and more, accumulated during more than a decade.

Deleting the application was the easy part. The important part was preserving the content. I had some foresight here, and all my blog posts were already in Markdown-formatted files.

Migrating to Next.js

I then used Vercel's v0 tool to create the first Next.js version of the website. It provided a useful visual starting point with an App Router application, pages, components, Tailwind CSS, and shadcn/ui. It produced an impressive result quickly, but it was still just a starting point.

The initial version contained more than one hundred new files, including dozens of UI components the website did not use. Some parts looked finished while the underlying structure still needed work. The application could render pages, but it was not yet the website I had envisioned.

Choosing an AI Coding Agent

From this point, I needed a strong AI coding agent to work with, to build the technical solution I wanted, in the way and with the structure I wanted. The main agents I used were Claude Code CLI, Codex CLI, and Codex App.

The harnesses and the AI models are changing constantly, with us being in the midst of a fierce race to the top between the frontier models. Despite benchmarks, published features, and measured differences, people easily base their preferences on feelings and how well a coding agent vibes with them (pun intended). I know that I did.

My experience with Claude vs. Codex was roughly this: Codex reads between the lines of my prompts extremely well and gets very close to what I intended to ask for. I've also found a good flow working with it. Claude produces great results, but burns tokens fast, sometimes does work I did not request, and bombards me with approval prompts for every little change.

At the time of writing this article, I found specifically that the Codex App had the UX that worked best for me personally. So, that was my primary tool, while complementing it with Claude Code for second opinions or when I ran out of token usage.

Token Optimization

I intentionally used the lowest tier subscriptions for both Codex and Claude, to see how far it could take me. This meant that I really needed to mind my token burn. This drove me to adopt some key patterns, to get the most output and best results for the least amount of tokens. I shortly considered installing the Caveman-skill to really minimize token usage but chose not to, as I wanted a realistic experience and to optimize in more conventional ways.

Another early task was updating the shadcn/ui setup and removing all components not used. That change alone removed thousands of lines from the repository. A key to saving tokens here was to tell the agent to use the shadcn CLI instead of reading and writing large source files directly from GitHub (which I once had to stop an agent from doing, mid-token apocalypse).

Better AI Agent Instructions

First, I ensured the project had a solid AGENTS.md to give the AI coding agent basic information about the project. The key here was to avoid including information which easily starts to drift with changes to the website.

Another important instruction was to tell the agent to read the latest Next.js documentation, included in the installed npm package, before making relevant changes. Instructions on formatting, linting, and building were also included.

I also added specialized agent skills for areas such as Next.js best practices, React best practices, shadcn/ui, and SEO. To ensure access across both Codex and Claude, I used Vercel's skills.sh.

AI Agent Iterative Development

The work was not a single conversion prompt followed by a finished website. It was an iterative development process where I remained responsible for the direction, while Codex handled most of the implementation.

First, I took the opportunity, while the codebase was still relatively small, to do larger sweeping operations with agents and set codebase-wide baselines. I installed Vercel's own skills for Next.js best practices and asked the agent to improve everything according to the best practices. It improved the codebase to better match Next.js conventions, reorganized code, improved SEO, implemented server actions, and simplified where possible.

The key workflow I used to ensure the best outcome and surprising effectiveness in token usage was the following points:

• Point out the exact entry point file for the change.
  • If changing the functionality or look of a page on the site, I pointed to the specific page.tsx file.
  • If the change was pure functionality, I pointed to the relevant file or files.
• I described the expected outcome of the functionality I wanted added.
  • If I knew of specific functional or technical limitations, I explicitly mentioned these.
• Default to medium effort on models. Use low or medium effort for very straight forward tweaks.
• For tweaks to implementations which could be improved, I pointed to the exact file and named function and variable names to focus on.
• Keep conversation threads short. Only stay in the same thread of changes as long as most of the context is relevant.

Explicitly pointing out where to look seemed to keep token usage down significantly. I very rarely hit the limits on the lowest tier subscriptions to Codex and Claude. That makes sense, since the AI probably doesn't have to scan as much of the file, or multiple files, to figure out where to start and where to make the changes.

It's important to note that this was highly efficient at the time of posting this blog. The harnesses and/or models might change/improve significantly over time.

Stabilize and Improve Content

The blog was one of the most important parts of the migration. Some posts have existed for more than fifteen years, and their URLs still receive traffic. Preserving those posts and their URLs mattered more than reproducing every detail of the old application.

The first Next.js version loaded the Markdown files using custom code. With Codex, I later introduced Velite to provide a clearer content model and build process.

After deliberating with both Codex and Claude, we decided to use Velite to structure the existing blog post content in Markdown format. This means each blog post now has validated frontmatter containing fields such as its title, publication date, summary, tags, image, series, and draft status. Velite processes the Markdown and produces structured data for Next.js.

This made several later improvements easier:

• Posts can be grouped into a series
• Tags can be sorted and filtered consistently
• Blog search can operate on structured content
• Draft posts are supported outside production
• RSS feeds and sitemaps can use the same content source
• Syntax highlighting can be applied during content processing

Codex helped implement these features incrementally. Blog search, for example, was added as a focused feature rather than as part of the original migration. The same was true for series navigation, improved code highlighting, responsive images, and fallback images.

Each change was small enough to understand and review, but together they preserved the previous blog experience and, in many ways, improved on it.

Moving Beyond a Direct Replacement

At first, the goal was to replace the old ASP.NET website. Once the new foundation was stable, the work became more interesting: I could start improving what the website actually communicated.

The old site had grown around sections created at different times. During the migration, I reconsidered whether those sections still represented me and my work. The start page was redesigned several times and my portfolio content was restructured quite a lot. Articles I've written and podcast appearances are now shown on the website. Conference talks and speaking information became more prominent.

Some of these changes began as broad requests such as improving the start page. Others were extremely specific, such as adjusting the behavior of a navigation button or changing the layout of a single conference talk.

Using Codex as a Reviewer

Codex was also useful when I did not have a specific implementation in mind.

I could ask it to review the website for unnecessary complexity, Next.js issues, SEO opportunities, or performance problems. It would inspect the current repository, identify concrete improvements, and implement the ones that made sense.

The important part was still reviewing the result. Codex can inspect a large amount of code quickly, but it does not own the product decisions. Some technically valid suggestions did not match the website I wanted. Others needed another iteration after I saw them in the browser.

The best results came from treating Codex as an engineering collaborator rather than as an automatic code generator.

Summary

This migration couldn't have been done without using modern AI coding agents. At least not within any reasonable time.

The AI agents played an important role, but not by performing one automatic conversion. Their role was closer to that of engineering collaborators: inspecting the existing work, implementing focused improvements, cleaning up generated code, following project-specific instructions, and helping me improve the process continuously.

The website moved from a server-side ASP.NET application with more than a decade of accumulated architecture to a content-focused Next.js application built around Markdown and reusable React components.

.NET, C#, and ASP.NET are still my main tools of choice when building high-performant, robust, testable, and long-lived solutions for serious organizations. ASP.NET for building APIs is still unmatched and C# is by far my favorite language. That said, Next.js and React are my favorites for server-side and client-side hybrid solutions for stable, dynamic, and expressive websites and web applications.

The migration gave me a modern website. More importantly, it solidified a collaboration process with AI coding agents which lets me make improvements, add features, or just do small tweaks extremely quickly and get them out to production within minutes. We really live in amazing times, and hopefully it'll only get better.

This blog post is about version 2 of my .NET Tool dotnet-cleanup. You can read the post about version 1 here: dotnet-cleanup: Clean Up Solution, Project & Folder.

The v2 of the tool has been rebuilt around directory-tree cleanup and glob patterns. Compared with the original solution-and-project-oriented version, the current version can be used on any directory with sub-directories including .NET projects, web-applications, or any combination of these. It can also be used on other types of directories by specifying which folders and files, with glob patterns, to clean up.

The tool command name remains dotnet-cleanup, with a hyphen.

Like with the previous version, one big USP (unique selling point) for this tool is that it removes the cleanup folders extremely fast, by first moving them to a temporary folder, before actually deleting them off disk.

Install the tool

Install dotnet-cleanup as a global .NET tool:

dotnet tool install --global dotnet-cleanup

Update an existing installation:

dotnet tool update --global dotnet-cleanup

Include and exclude directories

Add include patterns with --path or -p and exclude patterns with --exclude or -x:

dotnet-cleanup \
  -p "**/bin" \
  -p "**/obj" \
  -p "**/node_modules" \
  -x "**/samples/**"

This glob-based model is the biggest change from the original tool. It can clean generated directories across mixed .NET and web repositories without first resolving a solution or project file.

By default, the tool includes the following paths:

**/bin
**/obj
**/node_modules

Cleanup preview

The tool will first give you a list of matching files and directories, which will be deleted. You'll then have to actively confirm.

dotnet-cleanup

If you want to be totally sure that no files will actually be cleaned, add the --noop option:

dotnet-cleanup --noop

--noop lists matching directories without moving or deleting them. Use it before every new automated cleanup configuration.

CI/CD scenario: Auto confirm

To skip the confirmation prompt, for example when used inside a CI/CD solution, add --yes to automatically confirm the deletions:

dotnet-cleanup --yes

Customization

Matched directories are moved to a temporary directory before deletion by default. There are options provided for controlling that process, if needed:

dotnet-cleanup --no-move
dotnet-cleanup --no-delete
dotnet-cleanup --temp-path "D:\cleanup-temp"

Use --no-delete when you want the moved directories to remain available for inspection. Use --no-move only when direct deletion is acceptable.

Review the current options

The README and command-line help are the source of truth for current behavior:

dotnet-cleanup --help

Cleanup is destructive. Commit or stash work, run --noop, and review include and exclude patterns before confirming.

See the DotnetCleanup repository for the current README and source.

The original article documents the earlier solution-and-project-oriented implementation.

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.

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.

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.

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.

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:

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.

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.

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

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:

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

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.

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.

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);
    }
}

What about when an API limits your requests per second? This is probably something you would want to handle somewhere central in your code and not spread out everywhere where you make an HTTP call to the API.

For me, the solution was to add a Outgoing request middleware to the setup of the HttpClientFactory.

With this, I can just configure the startup services to use this RateLimitHttpMessageHandler-class with the HttpClientFactory:

services
    .AddHttpClient<IApi, Api>()
    .AddHttpMessageHandler(() =>
        new RateLimitHttpMessageHandler(
            limitCount: 5,
            limitTime: TimeSpan.FromSeconds(1)))
    .SetHandlerLifetime(Timeout.InfiniteTimeSpan);

This ensures that wherever I use the class IApi, through dependency injection, it will limit the calls to the API to only 5 calls per second.

The simplified version of code for the RateLimitHttpMessageHandler:

public class RateLimitHttpMessageHandler : DelegatingHandler
{
    private readonly List<DateTimeOffset> _callLog =
        new List<DateTimeOffset>();
    private readonly TimeSpan _limitTime;
    private readonly int _limitCount;

    public RateLimitHttpMessageHandler(int limitCount, TimeSpan limitTime)
    {
        _limitCount = limitCount;
        _limitTime = limitTime;
    }

    protected override async Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request,
        CancellationToken cancellationToken)
    {
        var now = DateTimeOffset.UtcNow;

        lock (_callLog)
        {
            _callLog.Add(now);

            while (_callLog.Count > _limitCount)
                _callLog.RemoveAt(0);
        }

        await LimitDelay(now);

        return await base.SendAsync(request, cancellationToken);
    }

    private async Task LimitDelay(DateTimeOffset now)
    {
        if (_callLog.Count < _limitCount)
            return;

        var limit = now.Add(-_limitTime);

        var lastCall = DateTimeOffset.MinValue;
        var shouldLock = false;

        lock (_callLog)
        {
            lastCall = _callLog.FirstOrDefault();
            shouldLock = _callLog.Count(x => x >= limit) >= _limitCount;
        }

        var delayTime = shouldLock && (lastCall > DateTimeOffset.MinValue)
            ? (limit - lastCall)
            : TimeSpan.Zero;

        if (delayTime > TimeSpan.Zero)
            await Task.Delay(delayTime);
    }
}

• Ownership of the files: If the solution used disappears tomorrow, you can still access my files.
• Predictable URLs: The URL to the resources should never change. You don't want to have to update all your blog-posts or other external links floating around the internet.
• Good tooling: Avoiding slow web-upload, when uploading multiple and/or large files, but also easily getting an overview of your files.
• (Bonus) Pretty URLs: "Pretty" looking URLs are easier to check for copy-paste errors, but could also potentially benefit SEO.
• (Bonus) Low or no cost: Since there are free services out there, paying for file-hosting must be worth it.

Non-fitting Alternatives

When I started evaluating alternatives, a while back, Flickr was still a thing. The problem was that I couldn't predictable directly link to an image I've uploaded. After feeling all the obstacles, which indicated that using Flickr for image-hosting was being actively blocked, I understood it was too much of a hack.

Historically, I've been using Google's image hosting through Blogger, which is where this blog started out. The problem was that this also felt like I hack and I was always worried that the URLs would change and I'd have to go through every single blog-posts I've ever made and update all images.

Services like Dropbox and Google Drive seem to actively try to block the use of their services for this, even if they are accessible through the web.

Azure Storage for easy web file-hosting

Enter Azure Storage, with its widespread adoption, familiar interface and extremely affordably priced Blob Storage. It checks off all my points in the checklist and more. Giving it's backing, it's fair to assume more functionality will be added ongoingly.

Azure Blob Storage can be used to store data-blobs of almost any size in the Azure-cloud. By providing a path/key, you can read or write to that "file" at that "path". The overall performance of Azure Storage is great and also an important feature of the service, but the simple mechanisms of Azure Blob Storage make it very fast.

Expose blob-content to the internet

So you could build a web-app which accesses your files on Azure Blob Storage and expose them through URLs in your API, but you can also let Azure handle that for you, by activating anonymous read access to your blobs.

You can do this on blob-level, so you can have a dedicated blob for public files, separately from your other blobs in the same Storage-account. These files will be read-only when you use the option Blob (anonymous read access for blobs only), found under the Access policy-section of the selected blob.

Upload files

Then you can use the Azure Portal, programmatically use the Azure Blob Storage API to upload files, or you can use application Azure Storage Explorer, for a friendly GUI-experience to get started.

Now you can share your files anywhere you want, via the provided URL from Azure or through a more pretty URL, using a custom domain.

Add a custom domain

To fulfill the criteria of pretty URLs, you can set your own custom domain for an Azure Storage-account. If you do not do this, the default URL for Azure Blob storage is https://{storage-account-name}.blob.core.windows.net/{file-path}.

Activate Azure CDN

This is a great start for your small project to start out with, but you can in the future easily transition into using the full power of Azure Content Delivery Network (Azure CDN) on your existing Azure Storage-account, simply by activating it from the Azure CDN-section in your Storage-account.

Minimally for this reason, and mostly for fun, I decided to write a .NET Core Global Tool which quickly generates one or multiple GUIDs/UUIDs, in whatever format could be needed.

Installation

Download the .NET Core SDK 2.1 or later. Then install the dotnet-guid .NET Global Tool, using the command-line:

dotnet tool install -g dotnet-guid

Usage

Usage: guid [arguments] [options]

Arguments:
  Count         Defines how may GUIDs/UUIDs to generate. Defaults to 1.

Options:
  -?|-h|--help  Show help information
  -n            Formatted as 32 digits:
                00000000000000000000000000000000
  -d            Formatted as 32 digits separated by hyphens:
                00000000-0000-0000-0000-000000000000
  -b            Formatted as 32 digits separated by hyphens, enclosed in braces:
                {00000000-0000-0000-0000-000000000000}
  -p            Formatted as 32 digits separated by hyphens, enclosed in parentheses:
                (00000000-0000-0000-0000-000000000000)
  -x            Formatted as four hexadecimal values enclosed in braces,
                where the fourth value is a subset of eight hexadecimal values that is also enclosed in braces:
                {0x00000000,0x0000,0x0000,{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}}
  -e            Defines if the GUIDs/UUIDs should be empty, using zero-values only.
  -u            Defines if the GUIDs/UUIDs generated should be upper-cased letters.

Examples

To get a single GUID/UUID, simply type:

guid

To get 3 random GUIDs/UUIDs, with letters in upper-case, formatted with brackets:

guid 3 -b -u

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

You can find a great list of more .NET Core Global Tools on GitHub, maintained by Nate McMaster.