When looking at the C# 14 updates coming out soon, I discovered a feature and thought, "how did this not already exist?" If you've been using C#'s null-conditional operators (?. and ?[]) for years like I have, you'll love the support for null-conditional assignments.

Our long null journey

It's been a long journey to improve how C# developers work with null, the billion-dollar mistake.

C# 2 kicked things off with nullable value types (like int? and bool?) because sometimes you need to know if someone didn't enter a number versus entering zero. With C# 6, we got null-conditional operators (?. and ?[]), letting us chain through potentially null objects without writing novels. C# 7 gave us pattern matching with is null checks that read like English. C# 8 came out with nullable reference types, the null-coalescing operator (??=), and the null-forgiving operator (!) for when you think you know better than the compiler. And, of course, C# 9 rounded it out with is not null because is null was feeling lonely.

For me, the null-conditional operators from C# 6 were a game-changer. Instead of doom-checking each level of potential nulls, I can just chain it.

// The old way
string? city = null;
if (customer != null && customer.Address != null)
{
    city = customer.Address.City;
}

// The new way
string? city = customer?.Address?.City;

This was great for reading values. However, we could never use the same trick for writing values. Enter C# 14.

The current problem

How many times have you written code like this?

if (customer != null)
  customer.Order = GetOrder(customer.Id)

If you're anything like me (lucky you), this pattern is burned into your memory. I type it without thinking. But we already have a perfectly good "do this thing if not null" operator. We just couldn't use it for assignments. Weird, yes? We could read through each null conditionally but not write through it. Every little assignment needed its own little null check guard.

The C# 14 solution

C# 14 lets you write this instead:

customer?.Order = GetOrder(customer.Id);

That's it! Clean, readable, and the intent is obvious: "If the customer isn't null, assign the current order to it."

The semantics are exactly what you'd hope for: the right-hand side (GetOrder(id)) only runs if the left-hand side isn't null. If customer is null, nothing happens — no assignment, no method call, and no exceptions.

For example, don't hide business logic. If null requires specific handling, explicit checks are much clearer.

// Less clear - what should happen if account is null?
account?.Balance += deposit;

// Better when null is exceptional
if (account is null)
    throw new InvalidOperationException("Cannot deposit to null account");
    
account.Balance += deposit;

Watch out for side effects! Remember, the entire right-hand side is skipped if the left is null.

// We don't call GetNextId() if the record is null
record?.Id = GetNextId();

Compound assignments

The real power in this improvement shows up when you use null-conditional assignments with compound assignment operators.

// Before C# 14
if (account != null)
{
    account.Balance += deposit;
}

// C# 14
account?.Balance += deposit;

This works with all compound assignment operators: +=, -=, *=, /=, %=, &=, |=, ^=, <<=, >>=, and ??=.

Check out this shopping cart example:

public class ShoppingCart
{
    public decimal Subtotal { get; set; }
    public decimal Tax { get; set; }
}

public void ApplyDiscount(ShoppingCart? cart, decimal discountAmount)
{
    // Only apply discount if cart exists
    cart?.Subtotal -= discountAmount;
    
    // Recalculate tax based on new subtotal
    cart?.Tax = cart.Subtotal * 0.08m;
}

Notice the improvements: no nested ifs, no ceremony, and just the expected "if it's there, update it" logic. Finally.

When this feature shines

Let's take a look at some brief real-world scenarios where null-conditional assignments are genuinely useful.

Optional dependencies

In modern apps, you have services everywhere — like logging, telemetry, caching, and so on — and it seems half of them are optional depending on what features are enabled.

public class TelemetryService
{
    private ILogger? _logger;
    private IMetricsCollector? _metrics;
    
    public void RecordEvent(string eventName, Dictionary<string, object> properties)
    {
        // Log only if logger is configured
        _logger?.LogInformation("Event recorded: {EventName}", eventName);
        
        // Track metrics only if collector is available
        _metrics?.EventCount += 1;
    }
}

With this improvement, our code doesn't get buried under a mountain of if (_logger != null) checks. The dependency is handled right where you use it, which means the happy path (the service is there) stays front and center. This is huge with classes that have multiple optional dependencies. Traditional null checks create a ton of noise that obscures what your code actually does.

Event handlers with optional subscribers

When you're working with events, subscribers are optional by nature. It's like me watching a football game: sometimes I'm listening and sometimes I'm not. And that's fine.

public class ProgressTracker
{
    public IProgress<int>? Progress { get; set; }
    private int _currentStep;
    private int _totalSteps;
    
    public void AdvanceProgress()
    {
        _currentStep++;
        var percentComplete = (_currentStep * 100) / _totalSteps;
        
        // Report only if someone is listening
        Progress?.Report(percentComplete);
    }
}

With this improvement, publishers don't need to defensively write null checks before every notification. This is great for library code or reusable components where you have zero control over whether consumers attach handlers. Plus, it's self-documenting. Progress?.Report() clearly says "if anyone cares, report progress."

Conditional updates with fluent APIs

Builder patterns and fluent APIs are obsessed with optional configuration. Sometimes you've set up all the pieces, and sometimes just a few.

public class ApplicationBuilder
{
    public DatabaseConfiguration? Database { get; set; }
    public ApiConfiguration? Api { get; set; }
    
    public void ApplyProduction()
    {
        // Safely configure only what exists
        Database?.ConnectionString = Environment.GetEnvironmentVariable("DB_PROD");
        Database?.CommandTimeout += TimeSpan.FromSeconds(30);
        
        Api?.RateLimitPerMinute = 1000;
        Api?.EnableCaching = true;
    }
}

With this example, configuration methods can be flexible without requiring everything to exist first. This is perfect for plugin architectures or systems where features come and go. You can write configuration code that gracefully handles a mix of initialized components without the spaghetti code.

Collection operations

We consistently work with collections that might not be initialized yet. Think of when you're doing lazy initialization for performance reasons.

public class CacheManager
{
    private List<string>? _recentItems;
    private Dictionary<string, object>? _settings;
    
    public void RecordAccess(string item)
    {
        // Add to recent items if cache is initialized
        _recentItems?.Add(item);
        
        // Update access count
        if (_settings?.ContainsKey("accessCount") == true)
        {
            _settings["accessCount"] = ((int)_settings["accessCount"]) + 1;
        }
    }
    
    public void UpdateTheme(string theme)
    {
        // Safe dictionary assignment
        _settings?.["theme"] = theme;
    }
}

Nice, eh? You can now work with collections that might not exist yet without checking if they exist first. This is great for performance-sensitive code where you want to defer allocating collections until you actually need them ... but you also want clean code. We can now keep the lazy initialization pattern without our code looking like a mess.

One gotcha: No ++ or –-

Don't kill the messenger: you can't use increment (++) or decrement (--) operators with null-conditional access.

// Ope
counter?.Value++;

If you want this pattern, do the traditional null check or use the compound assignment form.

counter?.Value += 1; 

Captain Obvious says: ++ and -- are a read and write operation rolled into one. And that's where semantics can get really weird with null-conditional operators. If counter is null, what should counter?.Value++ return? Null? The pre-increment value? The post-increment value that never computed? Instead of confusing everyone, it just isn't supported.

A "putting it all together" example: a configuration system

Let's put this all together with an example. Let's build a super-exciting configuration system that applies environment-specific overrides to application settings.

public class AppSettings
{
    public DatabaseConfig? Database { get; set; }
    public ApiConfig? Api { get; set; }
    public LoggingConfig? Logging { get; set; }
    public CacheConfig? Cache { get; set; }
}

public class DatabaseConfig
{
    public string? ConnectionString { get; set; }
    public int CommandTimeout { get; set; }
    public bool EnableRetry { get; set; }
}

public class ApiConfig
{
    public string? Endpoint { get; set; }
    public TimeSpan Timeout { get; set; }
    public int MaxRetries { get; set; }
}

public class ConfigurationUpdater
{
    public void ApplyEnvironmentOverrides(AppSettings? settings, Environment env)
    {
        // Database overrides - only if database config exists
        settings?.Database?.ConnectionString = env.GetVariable("DB_CONNECTION");
        settings?.Database?.CommandTimeout = 60;
        settings?.Database?.EnableRetry = true;
        
        // API configuration - compound assignments work too
        settings?.Api?.Endpoint = env.GetVariable("API_URL");
        settings?.Api?.Timeout += TimeSpan.FromSeconds(30);
        settings?.Api?.MaxRetries = 5;
        
        // Logging adjustments
        settings?.Logging?.Level = LogLevel.Information;
        settings?.Logging?.EnableConsole = env.IsDevelopment();
        
        // Cache settings
        settings?.Cache?.ExpirationMinutes += 15; 
    }
    
    public void ApplyDevelopmentDefaults(AppSettings? settings)
    {
        // Development-specific configuration
        settings?.Database?.EnableRetry = false; // Fail fast in dev
        settings?.Api?.Timeout = TimeSpan.FromSeconds(5); // Shorter timeouts
        settings?.Logging?.Level = LogLevel.Debug;
    }
}

This allows us to be modular. Not every app needs every config section. A simple POC might only touch database config, while our behemoth needs everything.

It also allows us to be optional by nature. The settings object itself might be null during early startup and individual sections might not be wired up yet. It be like that sometimes.

Compare it to the old way. To avert your eyes, I'll use a snippet.

// The verbose alternative (please don't do this)
if (settings != null)
{
    if (settings.Database != null)
    {
        settings.Database.ConnectionString = env.GetVariable("DB_CONNECTION");
        settings.Database.CommandTimeout = 60;
    }
    
    if (settings.Api != null)
    {
        settings.Api.Endpoint = env.GetVariable("API_URL");
        settings.Api.Timeout += TimeSpan.FromSeconds(30);
    }
}

That is a lot of ceremony just for "configure what exists." With null-conditional assignments, we get clean code that focuses on what we're configuring instead of whether we can configure it.

Wrapping up

Unless you're a language designer, C# 14's null-conditional assignment won't blow your mind. However, it will make your code clearer and easier to write. It takes a pattern we've all typed a thousand times and finally makes it as concise as it should have been all along.

So next time you catch yourself typing if (x != null) { x.Property = value; }, know there's a better way.

What patterns will you use with null-conditional assignments? Let me know in the comments, and happy coding!

Every year, Santa's workshop runs on data: delivery manifests, elf schedules, chimney dimensions, and naughty/nice scores. And like any other legacy system, it's held together with strings, DateTime comparisons, and hope.

In this post, let's modernize Santa's data parsing using modern C# features:

• DateOnly / TimeOnly
• IParsable<TSelf> / ISpanParsable<TSelf>
• Strongly typed IDs
• C# 14's new extension members

The goal here is for more safety, clearer intent, and better performance — all without turning the code into a Christmas puzzle.

The legacy Santa codebase

Here's a real "elves stay late" classic:

public void AssignGiftToElf(int giftId, int elfId, int workshopId)
{
  Console.WriteLine($"Assigning gift {giftId} to elf {elfId} in workshop {workshopId}");
}

AssignGiftToElf(elfId, giftId, workshopId); 

All of our parameters are int types. The compiler can't help you if you get the order wrong.

Santa's delivery logic isn't much better (sorry, children, this year not everything is delivered at midnight):

public class DeliveryWindow
{
    public DateTime DeliveryDate { get; set; }

    public DateTime StartTime { get; set; }
    public DateTime EndTime { get; set; }

    public bool IsDuringSleepingHours()
    {
        var startHour = StartTime.Hour;
        var endHour = EndTime.Hour;
        
        return startHour >= 22 || endHour <= 6;
    }
}

We're overusing DateTime for both pure dates and pure times. What time is on DeliveryDate? What date is attached to StartTime? What timezone are these in? You have to know tribal knowledge that isn’t expressed in the type system.

Let's see how we process our presents.

public class DeliveryOrder
{
    public int GiftId { get; set; }
    public int ElfId { get; set; }
    public int WorkshopId { get; set; }
    
    public DateTime DeliveryDate { get; set; }
    public DateTime WindowStart { get; set; }
    public DateTime WindowEnd { get; set; }
    
    public string? ChimneyDimensions { get; set; }
    public string? RecipientName { get; set; }
    public string? Address { get; set; }
}

The IDs are just int types (easy to mix up), dates and times are all DateTime (potentially confusing), and the ChimneyDimensions is a raw string we'll need to parse manually every time we need it.

These are potentially critical bugs that'll keep Santa's developers up late. Let's fix them together.

Use DateOnly and TimeOnly to say what you mean

First thing first: stop using DateTime when you don't actually mean date and time.

Here's a cleaner DeliveryWindow using DateOnly and TimeOnly:

public record DeliveryWindow
{
    public required DateOnly DeliveryDate { get; init; }
    public required TimeOnly WindowStart { get; init; }
    public required TimeOnly WindowEnd { get; init; }

    public bool IsDuringSleepingHours()
    {
        var sleepStart = new TimeOnly(22, 0); // 10 PM
        var sleepEnd = new TimeOnly(6, 0);    // 6 AM

        return WindowStart >= sleepStart || WindowEnd <= sleepEnd;
    }
}

Now the type tells you exactly what’s going on:

• DeliveryDate is a calendar date, no time, no timezone debates
• WindowStart / WindowEnd are times of day

There's also a performance bonus: DateOnly is half the size of DateTime.

Console.WriteLine(Unsafe.SizeOf<DateTime>());  // 8 bytes
Console.WriteLine(Unsafe.SizeOf<DateOnly>());  // 4 bytes
Console.WriteLine(Unsafe.SizeOf<TimeOnly>());  // 8 bytes

That may seem like a small difference, but not when you're storing millions of delivery records.

Starting with EF Core 8, DateOnly and TimeOnly are supported out of the box. DateOnly maps to the SQL date type, and TimeOnly maps to time.

Use strongly typed IDs for compile-time safety

Let's fix the "everything is an int" problem.

Instead of:

public void AssignGiftToElf(int giftId, int elfId, int workshopId)
{
    Console.WriteLine($"Assigning gift {giftId} to elf {elfId} in workshop {workshopId}");
}

AssignGiftToElf(elfId, giftId, workshopId); // Compiles, but there be bugs

Let's wrap each ID in its own type using readonly record struct:

public readonly record struct GiftId(int Value);
public readonly record struct ElfId(int Value);
public readonly record struct WorkshopId(int Value);

Now our method looks like this:

public void AssignGiftToElf(GiftId giftId, ElfId elfId, WorkshopId workshopId)
{
  Console.WriteLine($"Assigning gift {giftId} to elf {elfId} in workshop {workshopId}");
}

AssignGiftToElf(new ElfId(42), new GiftId(17), new WorkshopId(3));

The call now fails with a helpful error (Cannot convert from 'ElfId' to 'GiftId') instead of silently mis-routing gifts.

In terms of runtime overhead, see how the abstraction disappears after we compile:

using System;
using System.Runtime.CompilerServices;

Console.WriteLine(Unsafe.SizeOf<int>());
Console.WriteLine(Unsafe.SizeOf<GiftId>());
Console.WriteLine(Unsafe.SizeOf<ElfId>());
Console.WriteLine(Unsafe.SizeOf<WorkshopId>());

All four of these lines output 4, the same size as the underlying int.

As a bonus, our record struct update gives us value equality for free.

var id1 = new GiftId(42);
var id2 = new GiftId(42);
var id3 = new GiftId(43);

Console.WriteLine(id1 == id2); // true
Console.WriteLine(id1 == id3); // false
Console.WriteLine(id1.GetHashCode() == id2.GetHashCode()); // true

Use IParsable<TSelf> for generic parsing

Let's talk about our favorite topic: parsing.

Our original ChimneyDimensions is pretty ad-hoc:

public class ChimneyDimensions
{
    public double WidthInches { get; set; }
    public double HeightInches { get; set; }

    public static ChimneyDimensions Parse(string input)
    {
        var parts = input.Split('x');
        return new ChimneyDimensions
        {
            WidthInches = double.Parse(parts[0]),
            HeightInches = double.Parse(parts[1])
        };
    }

    public bool CanSantaFit() => WidthInches >= 20 && HeightInches >= 24;
}

Sure, this "works." (Imagine my air quotes.) But every type needs its own bespoke Parse method. There's no TryParse, no IFormatProvider for culture handling (important for Santa's global reach!), and we can't write generic code that parses multiple types the same way.

This is where IParsable<TSelf> comes in handy. While you can always write a Parse method, this makes sure your types easily work with generic utilities, framework features, and other developer code.

Let's evolve ChimneyDimensions into a modern, value-type version:

public readonly record struct ChimneyDimensions : IParsable<ChimneyDimensions>
{
    public double WidthInches  { get; init; }
    public double HeightInches { get; init; }

    public ChimneyDimensions(double width, double height)
        => (WidthInches, HeightInches) = (width, height);

    public static ChimneyDimensions Parse(string s, IFormatProvider? provider)
    {
        var i = s.IndexOf('x');
        if (i < 0)
            throw new FormatException($"Expected 'WIDTHxHEIGHT', got '{s}'");

        var width  = double.Parse(s[..i],     provider);
        var height = double.Parse(s[(i + 1)..], provider);
        return new(width, height);
    }

    public static bool TryParse(string? s, IFormatProvider? provider,
        out ChimneyDimensions result)
    {
        if (string.IsNullOrEmpty(s))
        {
            result = default;
            return false;
        }

        var i = s.IndexOf('x');
        if (i < 0 ||
            !double.TryParse(s[..i], provider, out var width) ||
            !double.TryParse(s[(i + 1)..], provider, out var height))
        {
            result = default;
            return false;
        }

        result = new(width, height);
        return true;
    }

    public bool CanSantaFit() => WidthInches >= 20 && HeightInches >= 24;

    public override string ToString() => $"{WidthInches}x{HeightInches}";
}

Now we can write generic parsing utilities once and reuse everywhere.

public static class GenericParser
{
    public static T Parse<T>(string value) where T : IParsable<T>
        => T.Parse(value, CultureInfo.InvariantCulture);

    public static IEnumerable<T> ParseMany<T>(IEnumerable<string> values)
        where T : IParsable<T>
        => values.Select(Parse<T>);
}

var giftId  = GenericParser.Parse<GiftId>("12345");
var chimney = GenericParser.Parse<ChimneyDimensions>("24x36");
var date    = GenericParser.Parse<DateOnly>("2024-12-25");

Use ISpanParsable<TSelf> for zero-allocation parsing

IParsable<TSelf> gives us generic parsing, but Santa's Workshop is stressing about performance. We have a 10GB delivery manifest to parse, and those string.Split() allocations add up. GC pressure is killing our throughput.

Our old way allocated strings for every field.

var parts = input.Split('x');  
var width = double.Parse(parts[0]);  
var height = double.Parse(parts[1]);

The Split call allocates a string[], and each new element is a new string object. Multiply that by millions of lines and we're on Santa's Naughty List.

ISpanParsable<TSelf> let us parse from ReadOnlySpan<char> (slices of the original string with zero allocations). We can then extend ChimneyDimensions:

public readonly record struct ChimneyDimensions :
    IParsable<ChimneyDimensions>, ISpanParsable<ChimneyDimensions>
{
    public double WidthInches  { get; init; }
    public double HeightInches { get; init; }

    public ChimneyDimensions(double width, double height)
        => (WidthInches, HeightInches) = (width, height);

    // string-based overload delegates to the span-based one
    public static ChimneyDimensions Parse(string s, IFormatProvider? provider)
        => Parse(s.AsSpan(), provider);

    public static ChimneyDimensions Parse(ReadOnlySpan<char> s, IFormatProvider? provider)
    {
        var i = s.IndexOf('x');
        if (i < 0)
            throw new FormatException("Expected 'WIDTHxHEIGHT'");

        var width  = double.Parse(s[..i],     provider);
        var height = double.Parse(s[(i + 1)..], provider);
        return new(width, height);
    }

    public static bool TryParse(string? s, IFormatProvider? provider,
        out ChimneyDimensions result)
    {
        if (string.IsNullOrEmpty(s))
        {
            result = default;
            return false;
        }

        return TryParse(s.AsSpan(), provider, out result);
    }

    public static bool TryParse(ReadOnlySpan<char> s, IFormatProvider? provider,
        out ChimneyDimensions result)
    {
        var i = s.IndexOf('x');
        if (i < 0 ||
            !double.TryParse(s[..i], provider, out var width) ||
            !double.TryParse(s[(i + 1)..], provider, out var height))
        {
            result = default;
            return false;
        }

        result = new(width, height);
        return true;
    }

    public bool CanSantaFit() => WidthInches >= 20 && HeightInches >= 24;

    public override string ToString() => $"{WidthInches}x{HeightInches}";
}

Now let’s parse an entire delivery manifest line.

First, the original approach uses Split, which allocates a string[] with nine elements:

public static DeliveryOrder ParseLineOldWay(string line)
{
    var parts = line.Split('|');
    
    return new DeliveryOrder
    {
        GiftId        = new GiftId(int.Parse(parts[0], CultureInfo.InvariantCulture)),  
        AssignedElf   = new ElfId(int.Parse(parts[1], CultureInfo.InvariantCulture)),  
        OriginWorkshop= new WorkshopId(int.Parse(parts[2], CultureInfo.InvariantCulture)), 
        DeliveryDate  = DateOnly.Parse(parts[3], CultureInfo.InvariantCulture),    
        WindowStart   = TimeOnly.Parse(parts[4], CultureInfo.InvariantCulture),    
        WindowEnd     = TimeOnly.Parse(parts[5], CultureInfo.InvariantCulture),    
        Chimney       = ChimneyDimensions.Parse(parts[6], CultureInfo.InvariantCulture),
        RecipientName = parts[7],
        Address       = parts[8]
    };
}

Allocations everywhere.

Our updated version uses a tiny helper:

static ReadOnlySpan<char> ReadField(ref ReadOnlySpan<char> line)
{
    var i = line.IndexOf('|');
    if (i < 0)
    {
        var field = line;
        line = ReadOnlySpan<char>.Empty;
        return field;
    }

    var result = line[..i];
    line = line[(i + 1)..];
    return result;
}

Now parsing the line is concise and allocation-friendly.

public static DeliveryOrder ParseLineNewWay(ReadOnlySpan<char> line)
{
    var giftId       = new GiftId(int.Parse(ReadField(ref line), CultureInfo.InvariantCulture));
    var elfId        = new ElfId(int.Parse(ReadField(ref line), CultureInfo.InvariantCulture));
    var workshopId   = new WorkshopId(int.Parse(ReadField(ref line), CultureInfo.InvariantCulture));
    var deliveryDate = DateOnly.Parse(ReadField(ref line), CultureInfo.InvariantCulture);
    var windowStart  = TimeOnly.Parse(ReadField(ref line), CultureInfo.InvariantCulture);
    var windowEnd    = TimeOnly.Parse(ReadField(ref line), CultureInfo.InvariantCulture);
    var chimney      = ChimneyDimensions.Parse(ReadField(ref line), CultureInfo.InvariantCulture);
    var recipient    = ReadField(ref line).ToString();
    var address      = ReadField(ref line).ToString();

    return new DeliveryOrder
    {
        GiftId        = giftId,
        AssignedElf   = elfId,
        OriginWorkshop= workshopId,
        DeliveryDate  = deliveryDate,
        WindowStart   = windowStart,
        WindowEnd     = windowEnd,
        Chimney       = chimney,
        RecipientName = recipient,
        Address       = address
    };
}

We still allocate strings for RecipientName and Address because we need to store them in the resulting object; everything else is parsed directly from span slices.

Use C# 14 extension members to extend everything

C# 14 introduces extension blocks, which let you add not just methods, but properties and static members to existing types.

With classic extension methods, you can only add methods. They always look like method calls:

public static class DeliveryOrderExtensions
{
    public static bool IsUrgent(this DeliveryOrder order)
        => order.DeliveryDate <= DateOnly.FromDateTime(DateTime.Today.AddDays(1));

    public static TimeSpan GetWindowDuration(this DeliveryOrder order)
        => order.WindowEnd.ToTimeSpan() - order.WindowStart.ToTimeSpan();
}

With no way to define extension properties, we have to use GetWindowDuration() instead of just WindowDuration.

C# 14 extension blocks change this. (Yes, I don't like the syntax either; don't kill the messenger!)

public static class DeliveryExtensions
{
    extension(DeliveryOrder order)
    {
        public bool IsUrgent
            => order.DeliveryDate <= DateOnly.FromDateTime(DateTime.Today.AddDays(1));

        public TimeSpan WindowDuration
            => order.WindowEnd.ToTimeSpan() - order.WindowStart.ToTimeSpan();

        public bool FitsChimney(double santaWidth, double santaHeight)
            => order.Chimney.WidthInches >= santaWidth &&
               order.Chimney.HeightInches >= santaHeight;

        public string ToManifestLine()
            => $"{order.GiftId}|{order.AssignedElf}|{order.OriginWorkshop}|" +
               $"{order.DeliveryDate:yyyy-MM-dd}|{order.WindowStart:HH:mm}|" +
               $"{order.WindowEnd:HH:mm}|{order.Chimney}|{order.RecipientName}|" +
               $"{order.Address}";
    }

    extension(DateOnly)
    {
        public static DateOnly ChristmasThisYear
            => new(DateTime.Today.Year, 12, 25);

        public static DateOnly NextChristmas()
        {
            var today     = DateOnly.FromDateTime(DateTime.Today);
            var christmas = new DateOnly(today.Year, 12, 25);

            return today > christmas
                ? new DateOnly(today.Year + 1, 12, 25)
                : christmas;
        }
    }
}

Now we can use extension properties like native properties—even more, static extensions appear directly on the type.

var order = new DeliveryOrder
{
    GiftId        = new GiftId(123),
    AssignedElf   = new ElfId(42),
    OriginWorkshop= new WorkshopId(3),
    DeliveryDate  = DateOnly.FromDateTime(DateTime.Today),
    WindowStart   = new TimeOnly(23, 0),
    WindowEnd     = new TimeOnly(23, 30),
    Chimney       = new ChimneyDimensions(24, 36),
    RecipientName = "Charlie",
    Address       = "123 Candy Cane Lane"
};

if (order.IsUrgent)
{
    Console.WriteLine($"Rush delivery! Window: {order.WindowDuration}");
}

if (order.FitsChimney(20, 24))
{
    Console.WriteLine("Santa approved!");
}

var christmas = DateOnly.ChristmasThisYear;
var next      = DateOnly.NextChristmas();

IsUrgent and WindowDuration are properties now, and ChristmasThisYear looks like it's built into DateOnly.

Putting it all together

Finally! Here's our modernized DeliveryOrder that uses everything we discussed.

public record DeliveryOrder
{
    public required GiftId GiftId { get; init; }
    public required ElfId AssignedElf { get; init; }
    public required WorkshopId OriginWorkshop { get; init; }
    public required DateOnly DeliveryDate { get; init; }
    public required TimeOnly WindowStart { get; init; }
    public required TimeOnly WindowEnd { get; init; }
    public required ChimneyDimensions Chimney { get; init; }
    public required string RecipientName { get; init; }
    public required string Address { get; init; }
}

Everything we wanted is more explicit:

• Strongly-typed IDs: we can't mix up GiftId with ElfId
• Clear date/time semantics: DateOnly for dates, TimeOnly for times
• Efficient parsing: IParsable<TSelf> and ISpanParsable<TSelf> let us share parsing logic and avoid allocations in hot paths
• Practical APIs: C# 14 extension members let us hang useful behavior (like IsUrgent and ToManifestLine) right off our domain types.

Think of these features as guardrails: they let the compiler catch mistakes that used to be runtime bugs — and they do it with zero or negligible runtime overhead.

Thanks for reading, happy holidays, and most importantly: happy parsing! 🎅

Since C# 3 dropped in 2007, C# developers have been using extension methods to add functionality to types without touching their source code. Whether you're extending types from the .NET BCL, third-party libraries, or even your own legacy code, extension methods have been essential to how we write C# code.

But there's always been one big limitation: you can only extend methods, not properties. The community has been impatiently waiting for that day to come.

With C# 14, that's about to change. Soon to ship with .NET 10 on November 11, 2025, Microsoft is introducing extension members, an expansion of the extension pattern that brings extension properties, extension indexers, and even static extension members to the language.

A quick primer on extension methods

Let's make sure we're all on the same page. Extension methods let you "add" methods to existing types without modifying them or creating derived types.

Here's a classic example:

public static class StringExtensions
{
    // Note the 'this' keyword on the first parameter
    public static string Capitalize(this string value)
    {
        if (string.IsNullOrEmpty(value))
            return value;
        return char.ToUpper(value[0]) + value.Substring(1).ToLower();
    }
}

// We call it as if it's an instance method of string
string name = "sara";
string capitalized = name.Capitalize(); // Returns "Sara"

The magic happens with the this keyword on the first parameter, which tells the compiler this is an extension method. Even though Capitalize is a static method in a static class, you call it as if it is an instance method on the string type (which we call the receiver type). IntelliSense picks it up and everyone's happy.

Extension methods are a core part of the .NET ecosystem and can be found in virtually every code base. For example, the classic LINQ methods like Where, Select, and OrderBy are all extension methods that make collections feel like they have built-in query capabilities. Even so, they are not without their limitations.

Limitations of extension methods

We all love extension methods — however, extension methods have always been limited to ... well, methods.

Let's say you're working with an API client and you're working with HTTP responses all day. You find yourself constantly checking status codes:

var response = await httpClient.GetAsync(url);

if ((int)response.StatusCode >= 200 && (int)response.StatusCode < 300)
{
    Console.WriteLine("Success!");
}
else if ((int)response.StatusCode >= 400 && (int)response.StatusCode < 500)
{
    Console.WriteLine("Client error - check your request");
}

That's ... not great. So you do what any good C# developer would do: create extension methods.

public static class HttpStatusCodeExtensions
{
    public static bool IsSuccess(this HttpStatusCode status)
    {
        return (int)status >= 200 && (int)status < 300;
    }
    
    public static bool IsClientError(this HttpStatusCode status)
    {
        return (int)status >= 400 && (int)status < 500;
    }
}

if (response.StatusCode.IsSuccess())
{
    Console.WriteLine("Success!");
}

This is better, but something feels off. You're calling IsSuccess() with parentheses, like it's doing work. But it's not really an action, it's a characteristic of the status code. It cries out "what are you?" and not "what can you do?"

At the risk of going back to CS101, methods represent actions and properties represent attributes and characteristics. When you want to know if a number is positive, you don't call number.IsPositive(). You'd naturally expect number.IsPositive.

For almost two decades, we've been writing methods when we wanted properties. We've added Get prefixes, used parentheses where they don't belong, and generally worked around this limitation.

Extension members in C# 14

C# 14 addresses this limitation with extension members. This new syntax introduces a dedicated extension block that allows you to define multiple kinds of extension members for a type, including properties, indexers, and static members.

Here's how it works. Instead of individual extension methods, you create an extension block.

public static class HttpStatusCodeExtensions
{
    extension(HttpStatusCode status)
    {
        public bool IsSuccess => (int)status >= 200 && (int)status < 300;
        public bool IsRedirect => (int)status >= 300 && (int)status < 400;
        public bool IsClientError => (int)status >= 400 && (int)status < 500;
        public bool IsServerError => (int)status >= 500 && (int)status < 600;
    }
}

var response = await httpClient.GetAsync(url);
if (response.StatusCode.IsSuccess)
{
    Console.WriteLine("Success!");
}
else if (response.StatusCode.IsClientError)
{
    Console.WriteLine("Client error - check your request");
}

Look at that. No parentheses. It reads like IsSuccess is an actual property of HttpStatusCode. Because now it is.

The extension declaration creates a block where status is your receiver (the instance you're extending). Everything inside can access status just like you'd access this in a regular class.

About that syntax...

I probably should have warned you about the extension block. That might take some getting used to, and I'm not alone. Many developers find it ugly and verbose, and I did at first. But much like the switch expression syntax, it's growing on me. (And after waiting almost two decades for this, I'll take what I can get.)

Plus, once you group related extension members together, it starts to make sense:

extension(HttpStatusCode status)
{
    // Properties for checking categories
    public bool IsSuccess => (int)status >= 200 && (int)status < 300;
    public bool IsClientError => (int)status >= 400 && (int)status < 500;
    
    // Property that uses other extension properties
    public string Category => status switch
    {
        _ when status.IsSuccess => "Success",
        _ when status.IsClientError => "Client Error",
        _ => "Unknown"
    };
}

In this example, everything related to HttpStatusCode extensions lives in one place.

According to the C# team, they explored many different design considerations: putting the receiver on every member (too repetitive), attaching the receiver to the static class (breaks existing patterns), extending this for properties (just, no), or other approaches that had breaking changes or complicated implementations.

The extension block won out because it doesn't break existing code (your regular extension methods keep working), it's flexible, allows grouping, and provides a place for the receiver to live. After all, since properties don't have parameters, where else would you declare a type you're extending?

Even better: Static extension members

Why stop there? This new feature supports static extension members, opening up new patterns for extending types.

You can define static extension members in an extension block without a receiver instance.

Let's add some factory methods and constants to HttpStatusCode :

public static class HttpStatusCodeExtensions
{
    // Static extension members - no instance needed
    extension(HttpStatusCode)
    {
        public static DefaultHttpStatusCode OK => HttpStatusCode.OK;
        public static DefaultHttpStatusCode NotFound => HttpStatusCode.NotFound;
        public static DefaultHttpStatusCode BadRequest => HttpStatusCode.BadRequest;
        
        public static HttpStatusCode FromInt(int code) => (HttpStatusCode)code;
    }
}

// Use them like built-in static members
var status = HttpStatusCode.DefaultOK;
var notFound = HttpStatusCode.DefaultNotFound;
var teapot = HttpStatusCode.FromInt(418); // I'm a teapot!

Notice the difference here? No receiver instance is in the extension declaration, just extension(HttpStatusCode). This lets you add static members that feel like they belong to the type itself.

This is perfect for factory patterns, type-specific constants, or utility methods that don't need an instance.

Building a complete solution

Let's put it all together and build something useful. We'll create a full set of extension members for working with HTTP status codes:

public static class HttpStatusCodeExtensions
{
    // Static extension members for common codes
    extension(HttpStatusCode)
    {
        public static DefaultHttpStatusCode OK => HttpStatusCode.OK;
        public static DefaultHttpStatusCode NotFound => HttpStatusCode.NotFound;
        public static DefaultHttpStatusCode BadRequest => HttpStatusCode.BadRequest;
        public static HttpStatusCode FromInt(int code) => (HttpStatusCode)code;
    }
    
    // Instance extension properties
    extension(HttpStatusCode status)
    {
        public bool IsSuccess => (int)status >= 200 && (int)status < 300;
        public bool IsRedirect => (int)status >= 300 && (int)status < 400;
        public bool IsClientError => (int)status >= 400 && (int)status < 500;
        public bool IsServerError => (int)status >= 500 && (int)status < 600;
        
        public string Category => status switch
        {
            _ when status.IsSuccess => "Success",
            _ when status.IsRedirect => "Redirect",
            _ when status.IsClientError => "Client Error",
            _ when status.IsServerError => "Server Error",
            _ => "Unknown"
        };
    }
}

Now look at how clean your HTTP client code becomes:

var response = await httpClient.GetAsync(url);

if (response.StatusCode.IsSuccess)
{
    var data = await response.Content.ReadAsStringAsync();
    Console.WriteLine($"Success! Category: {response.StatusCode.Category}");
}
else if (response.StatusCode.IsClientError)
{
    Console.WriteLine("Client error - check your request");
}
else if (response.StatusCode.IsServerError)
{
    Console.WriteLine("Server error - try again later");
}

More "real world" examples

Once you start working through extension properties, you'll find uses everywhere.

String validation

public static class StringExtensions
{
    extension(string str)
    {
        public bool IsEmpty => string.IsNullOrEmpty(str);
        public bool IsWhitespace => string.IsNullOrWhiteSpace(str);
        public bool IsValidEmail => !str.IsEmpty && 
            str.Contains("@") && str.Contains(".");
        public bool IsNumeric => !str.IsEmpty && str.All(char.IsDigit);
    }
}

string email = "sara@peloton.com";
if (!email.IsEmpty && email.IsValidEmail)
{
    Console.WriteLine("Valid email!");
}

Collection helpers

public static class CollectionExtensions
{
    extension<T>(ICollection<T> collection)
    {
        public bool IsEmpty => collection.Count == 0;
        public bool HasMultipleItems => collection.Count > 1;
        public bool HasSingleItem => collection.Count == 1;
    }
}

var items = new List<string> { "apple", "banana" };

// No more items.Count > 1
if (items.HasMultipleItems)
{
    Console.WriteLine("Multiple items found");
}

Checking state of async tasks

public static class TaskExtensions
{
    extension<T>(Task<T>)
    {
        public static Task<T> FromCancellation => 
            Task.FromCanceled<T>(new CancellationToken(true));
        
        public static Task<T> FromValue(T result) => 
            Task.FromResult(result);
    }
    
    extension<T>(Task<T> task)
    {
        public bool IsSuccessful => task.IsCompletedSuccessfully;
        public bool HasFailed => task.IsFaulted;
        public Exception? Error => task.Exception?.InnerException;
    }
}

// Usage
var task = Task.FromValue(42);
if (task.IsSuccessful)
{
    Console.WriteLine("All done!");
}

What about performance?

You're right to question performance with new language features. Luckily, extension members are syntactic sugar that compiles down to regular method calls, just like traditional extension methods. The CLR doesn't know (or care) that you used extension syntax.

Accessing response.StatusCode.IsSuccess generates identical IL code to calling an IsSuccess() method.

A few gotchas

While extension members are great, you'll want to know about a few limitations:

• No extension fields. You can't add fields to types through extensions; this means auto-properties like public string Status { get; set; } won't work because they technically require backing fields.
• Generic type parameter order. If the type isn't in the "receiver first, method second" order, it can't use the new syntax. I'd say this is rare, but if you have something like SelectLessThan<TResult, T> it'll have to stay as an extension method.

What this means for your code

Extension members, to me, aren't just a nice-to-have feature. They change how we think about extending C# types.

Think of API design: when you're writing libraries, you can provide extension points that finally feel like part of the type. Users won't have to remember if something is a method or a property. It'll be whatever makes most sense.

Wrapping up

With C# 14 and .NET 10, we finally have extension properties. We can now extend types with the syntax that makes sense. We can stop pretending that characteristics are actions.

Is the extension block weird and different? Yes. Will we get used to it? Probably.

How will you use extension members? Let me know in the comments, and happy coding!

This is the final part of our six‑part deep dive into .NET Aspire.

• Part 1: What Is .NET Aspire?
• Part 2: Exploring the Developer Dashboard
• Part 3: Service Defaults
• Part 4: Integrations
• Part 5: Orchestration & Service Discovery
• This post (Part 6): Deployment Using Azure Container Apps

Welcome back. Time to ship this thing.

During this series, we’ve gone from learning what .NET Aspire is, to exploring the dashboard, and service defaults, integrations and service discovery.

If you’ve been coding along, you’ve probably enjoyed how Aspire makes local development approachable. We’ve spun up APIs, databases, a Blazor frontend and a Redis cache and watched them all come alive in a single “mission control” dashboard.

But production doesn’t run on localhost:5000 (trust me, I’ve tried). Today, we’re deploying Azure Container Apps using the Azure Developer CLI (azd), and I will show you how the proverbial sausage gets made.

The Evolving Deployment Story

Since the initial release of Aspire, the deployment story has significantly matured. With Aspire 9.2 and later, Microsoft introduced a new publishing model that gives you more flexibility in how and where you deploy your applications.

The original process generates a manifest file that the azd CLI consumes to provision infrastructure. This is great for Azure deployments but is very opaque.

Aspire 9.2 and later introduces the aspire publish and aspire deploy commands with extensible publishers. With this new process, you can now generate Docker Compose files, Kubernetes manifests, Bicep templates or even custom publishers. While the manifest format still exists, many are favoring this more flexible approach.

For Azure deployments specifically, azd remains the recommended path and is what we’ll use in this article. It has first-class Aspire support and handles the entire workflow from provisioning to deployment. If you need more extensibility, consider the publisher model.

Why Are We Deploying to Azure Container Apps?

If you’ve reached this point, you might be asking: why ACA? After all, we could throw our Aspire services on a VM, App Service, Azure Kubernetes Service (AKS) or even good old IIS.

Here’s why ACA and Aspire make sense for us:

• Serverless containers. With ACA, we don’t manage VMs or clusters. ACA scales your containers based on demand. Because Aspire apps are often microservice-y by nature, ACA fits us well.
• Built-in Dapr support. Aspire leans on Dapr for service-to-service communication and other benefits. ACA lets you enable Dapr sidecars with a single setting, which is less plumbing that we need to maintain.

Don’t worry, I’m not getting paid by Microsoft. It’s not all sunshine and rainbows. Aside from the obvious vendor lock-in, ACA also comes with:

• Opaque scaling rules. ACA’s autoscaling works well, but in many cases tuning it can feel like trial and error. You’ll need to experiment and test thoroughly to avoid cold starts or runaway costs.
• Debugging complexity. While the local Aspire dashboard is great to use, debugging distributed Aspire services running in ACA is less so. While logging and observability help, the gap is real.

ACA is definitely Azure’s fastest path to the cloud. You trade some control for simplicity. Depending on your goals, that may be a fair tradeoff.

The Database Question: To Containerize in the Cloud or Not?

For local development, Aspire apps typically run SQL Server in a container. This makes complete sense: you need a database to develop against, and containerized SQL spins up quickly alongside your APIs.

But when you move to production, you need to make a decision: containerize the database or use a managed service?

If you decide to containerize SQL server, you see:

• A familiar setup, just like locally
• Everything runs in containers, giving you symmetry between local development and your cloud environments
• That it’s fast to set up and tear down

However, you’ll see some drawbacks:

• Persistence becomes your problem. Unless you’ve carefully configured volumes, you risk losing data when you restart the container
• Congratulations, you are now responsible for patching, scaling, backups and high availability
• Databases are stateful; ACA is best for stateless workloads

If you decide to use an Azure SQL Database, you see:

• A fully managed database: backups, scaling and security patches are all managed by Microsoft
• High availability out of the box
• It integrates with managed identity, preventing manual management of passwords and tokens

Some drawbacks:

• It costs more than a containerized SQL instance
• It isn’t “free” to tear down and spin up like a container
• Some features differ from full SQL Server (though for most use cases, it’s a non-issue)

In my experience, most teams run containerized SQL for development and Azure SQL (or another managed cloud database) for production use cases. Aspire does make this easy; just point your connection string to Azure SQL instead of a container. With DefaultAzureCredential, your app can authenticate securely without storing a password.

A pragmatic path is usually best. When it comes to production, databases are too critical to treat as disposable containers.

Prepare Aspire Services for Deployment

Your Aspire solution likely has several components. For what we’ve developed in this series, we have:

• Inventory API: Tracks in-stock guitars
• Orders API: Places customer orders and validates stock against Inventory
• Blazor frontend: The user interface that calls the API behind the scenes
• Redis cache: A cache that speeds up reads in our Blazor app
• SQL database: Our database layer (we’ll be using Azure SQL for production)

Locally, Aspire’s AppHost orchestrates all these. But in ACA, each service becomes its own container with its own lifecycle.

This changes a few things:

• Networking. Locally, Aspire wires up services with simple hostnames. In ACA, we’ll learn on Dapr service IDs or ACA-managed DNS.
• Configuration. Locally, appsettings.json or secrets.json carries secrets. In ACA, our secrets will come from Azure Key Vault or ACA environment variables.
• Scaling. Locally, everything runs together. In ACA, each service can scale independently. For example, our Inventory API may need more replicas than our Blazor app.

While Aspire gives us the glue to hold our services together, we still need to think of each service as independently deployable.

Deploy with azd: The Happy Path

With our deployment, everything starts with azd init, which provides customized support for .NET Aspire projects. To get started, you’ll need to install the Azure Developer CLI.

This diagram, respectfully stolen from the Microsoft documentation, gives a great overview of how azd runs its deployments.

For more in-depth details, please check out the docs. To simplify: azd produces an Aspire manifest file, the azd provision call generates Bicep files, a deployment triggers using Azure Resource Manager (ARM) APIs, azd deploy executes with the same manifest file, azd makes a call to dotnet publish to generate container images, azd pushes images to an ACR registry, and, finally, azd uses the new version of the image.

Let’s walk through a successful deployment. I’ll walk through the commands and explain what’s happening at each step.

Step 1: Initialize the Project

From your root directory (where your .sln file lives):

azd init

You’ll see the following prompt:

? How do you want to initialize your app?
> Use code in the current directory
  Select a template

We’ll select Use code in the current directory. Next, azd scans your directory and detects your AppHost project:

Detected services:

  .NET (Aspire)
  Detected in: C:\code\AspireGuitarShop\AspireGuitarShop.AppHost\AspireGuitarShop.AppHost.csproj

azd will generate the files necessary to host your app on Azure using Azure Container Apps.

? Select an option
> Confirm and continue initializing my app
  Cancel and exit

Select Confirm and continue initializing my app. Then, enter an environment name (like dev or production).

? Enter a unique environment name: dev

Generating files to run your app on Azure:

  (✓) Done: Generating ./azure.yaml
  (✓) Done: Generating ./next-steps.md

SUCCESS: Your app is ready for the cloud!
You can provision and deploy your app to Azure by running the azd up command in this directory.

This creates several files:

• azure.yaml describes the services
• .azure/config.json stores the environment configuration
• .azure/dev/.env contains environment-specific settings

Step 2: Deploy to Azure

Enter this simple command:

azd up

With this single command, azd:

• Authenticates you to Azure
• Prompts you for your subscription and location
• Provisions your Azure resources
• Builds and pushes your container images
• Deploys your services

You’ll see output like the following:

? Select an Azure Subscription to use:
> 1. Your Subscription (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)

? Select an Azure location to use:
> 44. (US) East US 2 (eastus2)

? Select which services to expose to the Internet
> frontend

Packaging services (azd package)

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

  Subscription: Your Subscription
  Location: East US 2

  (✓) Done: Resource group: rg-dev-xxxx
  (✓) Done: Container Registry: crdevxxxx
  (✓) Done: Log Analytics workspace: log-dev-xxxx
  (✓) Done: Container Apps Environment: cae-dev-xxxx

SUCCESS: Your application was provisioned in Azure in 1 minute 13 seconds.

Deploying services (azd deploy)

  (✓) Done: Deploying service inventoryapi
    - Endpoint: inventoryapi.xxxx.eastus2.azurecontainerapps.io/

  (✓) Done: Deploying service ordersapi
    - Endpoint: ordersapi.xxxx.eastus2.azurecontainerapps.io/

  (✓) Done: Deploying service frontend
    - Endpoint: frontend.xxxx.eastus2.azurecontainerapps.io/

  Aspire Dashboard: https://dashboard.xxxx.eastus2.azurecontainerapps.io/

SUCCESS: Your up workflow to provision and deploy to Azure completed in 3 minutes 50 seconds.

Do you see the link to the Aspire dashboard at the bottom? This is fully supported as of Aspire 9.2, giving you the same experience in production that you have in your local environment.

What azd Deployed

If we navigate to the Azure portal, we’ll see:

• Container registry: A repository for our container images. Each of our services (Inventory API, Orders API, Frontend) gets pushed here as a container image.
• Log analytics workspace: Collects logs and metrics from all our services. This feeds into Application Insights.
• Container apps environment: The logical boundary for our Container Apps (think of it as a cluster that the containers run in).
• Individual container apps: We have one for each service in our AppHost. Because of this, each Container App scales independently.
• Managed identities: With Aspire 9.2, each Container App gets its own managed identity by default.

The Bicep layer

Behind the scenes, azd generated Bicep templates to provision our infrastructure. We can generate them explicitly with the following command:

azd infra generate

This generates an infra folder with Bicep files. What’s inside?

First is a main.bicep file that orchestrates the entire deployment. It creates the resource group and calls other modules.

targetScope = 'subscription'

@minLength(1)
@maxLength(64)
@description('Name of the environment that can be used as part of naming resource convention, the name of the resource group for your application will use this name, prefixed with rg-')
param environmentName string

@minLength(1)
@description('The location used for all deployed resources')
param location string

@description('Id of the user or app to assign application roles')
param principalId string = ''

@metadata({azd: {
  type: 'generate'
  config: {length:22,noSpecial:true}
  }
})
@secure()
param cache_password string
@secure()
param password string

var tags = {
  'azd-env-name': environmentName
}

resource rg 'Microsoft.Resources/resourceGroups@2022-09-01' = {
  name: 'rg-${environmentName}'
  location: location
  tags: tags
}
module resources 'resources.bicep' = {
  scope: rg
  name: 'resources'
  params: {
    location: location
    tags: tags
    principalId: principalId
  }
}


output MANAGED_IDENTITY_CLIENT_ID string = resources.outputs.MANAGED_IDENTITY_CLIENT_ID
output MANAGED_IDENTITY_NAME string = resources.outputs.MANAGED_IDENTITY_NAME
output AZURE_LOG_ANALYTICS_WORKSPACE_NAME string = resources.outputs.AZURE_LOG_ANALYTICS_WORKSPACE_NAME
output AZURE_CONTAINER_REGISTRY_ENDPOINT string = resources.outputs.AZURE_CONTAINER_REGISTRY_ENDPOINT
output AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID string = resources.outputs.AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID
output AZURE_CONTAINER_REGISTRY_NAME string = resources.outputs.AZURE_CONTAINER_REGISTRY_NAME
output AZURE_CONTAINER_APPS_ENVIRONMENT_NAME string = resources.outputs.AZURE_CONTAINER_APPS_ENVIRONMENT_NAME
output AZURE_CONTAINER_APPS_ENVIRONMENT_ID string = resources.outputs.AZURE_CONTAINER_APPS_ENVIRONMENT_ID
output AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN string = resources.outputs.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN
output SERVICE_SERVER_VOLUME_GUITARDATA_NAME string = resources.outputs.SERVICE_SERVER_VOLUME_GUITARDATA_NAME
output AZURE_VOLUMES_STORAGE_ACCOUNT string = resources.outputs.AZURE_VOLUMES_STORAGE_ACCOUNT

Next, we have resources.bicep. This file defines the actual Azure resources.

@description('The location used for all deployed resources')
param location string = resourceGroup().location
@description('Id of the user or app to assign application roles')
param principalId string = ''


@description('Tags that will be applied to all resources')
param tags object = {}

var resourceToken = uniqueString(resourceGroup().id)

resource managedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: 'mi-${resourceToken}'
  location: location
  tags: tags
}

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2023-07-01' = {
  name: replace('acr-${resourceToken}', '-', '')
  location: location
  sku: {
    name: 'Basic'
  }
  tags: tags
}

resource caeMiRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(containerRegistry.id, managedIdentity.id, subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d'))
  scope: containerRegistry
  properties: {
    principalId: managedIdentity.properties.principalId
    principalType: 'ServicePrincipal'
    roleDefinitionId:  subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d')
  }
}

resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
  name: 'law-${resourceToken}'
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
  tags: tags
}

resource storageVolume 'Microsoft.Storage/storageAccounts@2022-05-01' = {
  name: 'vol${resourceToken}'
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
  properties: {
    largeFileSharesState: 'Enabled'
  }
}

resource storageVolumeFileService 'Microsoft.Storage/storageAccounts/fileServices@2022-05-01' = {
  parent: storageVolume
  name: 'default'
}

resource serverGuitarDataFileShare 'Microsoft.Storage/storageAccounts/fileServices/shares@2022-05-01' = {
  parent: storageVolumeFileService
  name: take('${toLower('server')}-${toLower('guitardata')}', 60)
  properties: {
    shareQuota: 1024
    enabledProtocols: 'SMB'
  }
}

resource containerAppEnvironment 'Microsoft.App/managedEnvironments@2024-02-02-preview' = {
  name: 'cae-${resourceToken}'
  location: location
  properties: {
    workloadProfiles: [{
      workloadProfileType: 'Consumption'
      name: 'consumption'
    }]
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalyticsWorkspace.properties.customerId
        sharedKey: logAnalyticsWorkspace.listKeys().primarySharedKey
      }
    }
  }
  tags: tags

  resource aspireDashboard 'dotNetComponents' = {
    name: 'aspire-dashboard'
    properties: {
      componentType: 'AspireDashboard'
    }
  }

}

resource serverGuitarDataStore 'Microsoft.App/managedEnvironments/storages@2023-05-01' = {
  parent: containerAppEnvironment
  name: take('${toLower('server')}-${toLower('guitardata')}', 32)
  properties: {
    azureFile: {
      shareName: serverGuitarDataFileShare.name
      accountName: storageVolume.name
      accountKey: storageVolume.listKeys().keys[0].value
      accessMode: 'ReadWrite'
    }
  }
}

output MANAGED_IDENTITY_CLIENT_ID string = managedIdentity.properties.clientId
output MANAGED_IDENTITY_NAME string = managedIdentity.name
output MANAGED_IDENTITY_PRINCIPAL_ID string = managedIdentity.properties.principalId
output AZURE_LOG_ANALYTICS_WORKSPACE_NAME string = logAnalyticsWorkspace.name
output AZURE_LOG_ANALYTICS_WORKSPACE_ID string = logAnalyticsWorkspace.id
output AZURE_CONTAINER_REGISTRY_ENDPOINT string = containerRegistry.properties.loginServer
output AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID string = managedIdentity.id
output AZURE_CONTAINER_REGISTRY_NAME string = containerRegistry.name
output AZURE_CONTAINER_APPS_ENVIRONMENT_NAME string = containerAppEnvironment.name
output AZURE_CONTAINER_APPS_ENVIRONMENT_ID string = containerAppEnvironment.id
output AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN string = containerAppEnvironment.properties.defaultDomain
output SERVICE_SERVER_VOLUME_GUITARDATA_NAME string = serverGuitarDataStore.name
output AZURE_VOLUMES_STORAGE_ACCOUNT string = storageVolume.name

In a real-world environment, you’ll need to update these to accommodate dependencies, networking and security rules, and so on.

Finally, we have the main.parameters.json file, which stores our, well, parameters.

.json{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
      "principalId": {
        "value": "${AZURE_PRINCIPAL_ID}"
      },
      "cache_password": {
        "value": "${AZURE_CACHE_PASSWORD}"
      },
      "password": {
        "value": "${AZURE_PASSWORD}"
      },
      "environmentName": {
        "value": "${AZURE_ENV_NAME}"
      },
      "location": {
        "value": "${AZURE_LOCATION}"
      }
    }
  }

So, why Bicep? Let’s talk about why Microsoft chose it for Aspire deployments.

For the uninitiated, Bicep is Azure’s domain-specific language (DSL) for deploying resources. Think of it as a friendly wrapper around ARM (Azure Resource Manager) templates. Where ARM templates are verbose JSON documents, Bicep is concise, readable and suited for your Azure cloud deployments.

You might also be wondering: why not Terraform? For me, I view Terraform as the Switzerland of the infrastructure-as-code landscape: neutral, reliable and works everywhere.

Here’s why we’re opting for Bicep over Terraform:

• Native Azure integration. Bicep has zero-day support for new Azure features—no waiting for provider updates.
• No state management. Bicep deployments are stateless; ARM is your state. No need to worry about state file corruption, backend configuration or state locks.
• Tighter IDE support. Visual Studio and VS Code give you IntelliSense for every Azure resource property.
• Azure-specific optimizations. Features like template specs and Azure blueprints only work with ARM/Bicep.

Of course, Terraform is an IaC leader for a reason. It shines when you need multi-cloud deployments, a massive ecosystem, mature tooling and explicit state. For Aspire specifically, Bicep makes more sense. The azd CLI generates Bicep automatically from our AppHost, and the integration is seamless.

Other Considerations

Before we finish discussing our Aspire deployment to Azure Container Apps, I’d like to walk through some final considerations.

Service-to-Service Communication with Dapr

One of Aspire’s biggest strengths is its embrace of Dapr. Without Dapr, service-to-service communication can be brittle—you hard-code hostnames, deal with manual retries and hope DNS resolves correctly.

With Dapr, services talk to each other using logical IDs. Dapr then handles retries, security and observability.

In our AppHost, we have:

var inventoryApi = builder.AddProject<Projects.Api>("inventoryapi")
    .WithReference(inventoryDb)
    .WithReference(cache);

var ordersApi = builder.AddProject<Projects.OrdersApi>("ordersapi")
    .WithReference(orderDb)
    .WithReference(inventoryApi);

When Orders API needs to call Inventory API, it doesn’t use http://inventoryapi:8080. Instead, it uses Dapr service invocation:

var response = await httpClient.GetAsync("http://inventoryapi/api/guitars");

Aspire’s service discovery wires this up automatically. In ACA, you enable Dapr in the Container App configuration, and it just works.

Managing Secrets with Azure Key Vault

Secrets are where cloud deployments often get messy. Many times, developers hard-code them locally then scramble to hide them in production. In ACA, the best practice is to use Azure Key Vault to store your secrets.

Here’s a typical flow:

1. Store secrets in Key Vault, like database passwords and API keys
2. Use managed identities so your ACA cotnainers can access Key Vault securely
3. Reference secrets in your container’s environment variables

As we saw earlier in this series, our AppHost defines parameters:

var password = builder.AddParameter("password", secret: true);
var server = builder.AddSqlServer("server", password);

When we deploy with azd, we’re prompted for the password value and it gets stored in Key Vault automatically. Then, our Container Apps retrieve it at runtime using their managed identities. This way, we have no exposed passwords.

Observability in Production

The Aspire dashboard is great locally. When you deploy to ACA, you get the dashboard in production too (as of Aspire 9.2 and later), but you’ll also want to leverage Azure’s native observability tools.

As we’ve learned, Azure emits telemetry using OpenTelemetry by default. Configure your exporters to send data to Azure:

• Logs. Application Insights collects logs per service
• Metrics. Azure Monitor tracks CPU, memory and requests
• Traces. Distributed traces flow across services, letting us see request journeys end-to-end

The caveat? Azure’s tools are powerful but can be overwhelming. Application Insights can generate mountains of logs and KQL takes learning. Costs grow with data volume.

The tradeoff here is Aspire giving you easy local observability, and ACA giving us scalable but more complex observability.

Scaling and Cost Management

Scaling is ACA’s party trick: using Kubernetes Event-driven Autoscaling (KEDA) rules, you can scale services up or down based on CPU, memory or even custom events. To save some coin, services can scale to zero when idle.

Scaling isn’t truly free, though. Cold starts mean your first request might take seconds. If your users expect instant responses, scaling to zero might frustrate them.

Costs can quickly add up because of:

• Log ingestion fees from Application Insights
• Idle services that don’t quite scale to zero
• Over-provisioning because of cold start concerns

Start conservative, monitor and adjust. Aspire helps you design services to scale, but ACA billing enforces reality.

Honest Tradeoffs

Stepping back a bit, what’s the big picture?

With Aspire and ACA, we have an easy path from local development to cloud deployments, simple Dapr service discovery, strong Azure integration with its other resources, and serverless containers that can scale automatically.

It isn’t without drawbacks. We often experience cold starts and scaling quirks, debugging difficulties and no easy portability outside of Azure.

There is no free lunch. Aspire and ACA is excellent for Azure-first teams who want cloud-native deployments without the complexity of Kubernetes. If you need portability or fine-grained control, AKS might be a better choice.

Conclusion

And with that, we’ve reached the end of our Aspire journey. We explored Aspire’s dashboard, defaults, integration and service discovery. Now we’ve seen how to take it all the way to production.

While the Aspire deployment story is still evolving, it shows you that it isn’t just for local development and can also be a framework to help you succeed in the cloud. And while ACA comes with tradeoffs, it gives you a fast, integrated way to run Aspire services at scale.

As with any technology, there is much more to explore. Check out the Aspire docs, start building and let me know how it goes. Happy coding!

This is Part 5 of our six‑part deep dive into .NET Aspire.

• Part 1: What is .NET Aspire?
• Part 2: Exploring the Developer Dashboard
• Part 3: Service Defaults
• Part 4: Integrations
• This post (Part 5): Orchestration & Service Discovery
• Part 6: Deployment Using Azure Container Apps

Welcome back, friends. We’re really cooking with gas now.

Up to this point, we’ve:

• Said “hello, world” to .NET Aspire and learned why an application model beats a folder full of ad-hoc Docker Compose files
• Poked around the Developer Dashboard to watch our app light up in real-time
• Saw how Service Defaults added opinionated capabilities like OpenTelemetry, health probes and resilience across every service with one line of code
• Plugged SQL Server and Redis into the mix

We’ve had a lot of fun so far, but up to this point we’ve been hosting a party of one: an Inventory API that lists guitars for sale. Today, we’ll introduce a brand-new Orders API, teach it how to talk to Inventory, and see how the Aspire orchestrator handles all the messy wiring for us.

Note: This series focuses on .NET Aspire and not writing APIs, so I’ll be assuming you have general working knowledge of how to write C# APIs. I will explain new code where relevant.

Why Orchestration Matters

Why does orchestration matter? Docker Compose and Kubernetes absolutely help with scheduling containers, but they live outside of your codebase. Your CI pipeline has to juggle a bunch of YAML files, keep ports in sync and pray nobody commits a hard‑coded endpoint by mistake.

With Aspire, orchestration moves back into C#. You declare what exists and how pieces relate.

• Lifecycle: Databases come online before the APIs that depend on them.
• Configuration: Connection strings, secrets and URLs flow in through environment variables.
• Resilience and telemetry: Opt in once with AddServiceDefaults() and every outbound call is wrapped with retries, time‑outs and OpenTelemetry spans.

In short, with Aspire orchestration is the central hub that knows the dependency graph, watches health probes and keeps secrets safe. No more depending on a dated README.md and launching nine terminals.

Revisiting Service Defaults

Before we start wiring up new services, let’s revisit service defaults. In our previous post, we saw how a single call to builder.AddServiceDefaults() adds OpenTelemetry instrumentation, health probes, service discovery and a resilience pipeline. Those defaults apply to every ASP.NET Core project that opts in by calling builder.AddServiceDefaults().

This allows service defaults to do the heavy lifting for orchestration. When the AppHost injects environment variables like ConnectionStrings__guitardb, our services automatically pick them up through configuration binding. Telemetry flows to the dashboard without any extra code. And when we call another service via HttpClient, the standard resilience handler adds retries, timeouts and circuit breakers.

We won’t rehash all of the implementation details here—see Part 3 for in-depth details. However, keep in mind that everything we build in this post rests on these conventions.

Meet the Orders API

Our guitar shop currently consists of a Blazor frontend and a single Inventory (/guitars) API that handles basic create-read-update-delete (CRUD) operations. We’ll now introduce an Orders API.

The Orders API will:

1. Accept an order from our Blazor app
2. For each line item, ask the Inventory API whether the product exists and has stock
3. If validation passes, calculate tax, persist the order and reply 201 Created with an order summary

Note: For clarity and conciseness, the following code is under a single endpoint. For a “real-world” production app, much of this logic will live in other parts of your application.

Build the Endpoint

Let’s create the Orders API. Let’s take a look at our POST endpoint. I’ll walk you through it next.

app.MapPost("/orders", async (CreateOrderRequest req,
                              OrdersDbContext db,
                              InventoryClient inventory) =>
{
    if (!req.Lines.Any())
        return Results.BadRequest("At least one line is required.");

    var validatedLines = new List<OrderLine>();
    foreach (var line in req.Lines)
    {
        var product = await inventory.GetAsync(line.ProductId);
        if (product is null) return Results.BadRequest($"Product {line.ProductId} not found");
        if (product.Stock < line.Quantity) return Results.BadRequest($"Insufficient stock for {product.Sku}");

        validatedLines.Add(new OrderLine
        {
            ProductId  = line.ProductId,
            Quantity   = line.Quantity,
            UnitPrice  = product.Price
        });
    }

    var subtotal = validatedLines.Sum(l => l.LineTotal);
    var tax = Math.Round(subtotal * 0.05m, 2);

    var order = new Order
    {
        CustomerName = req.CustomerName,
        Subtotal     = subtotal,
        Tax          = tax,
        Lines        = validatedLines
    };

    db.Orders.Add(order);
    await db.SaveChangesAsync();

    return Results.Created($"/orders/{order.Id}",
        new { order.Id, order.OrderNumber, order.Subtotal, order.Tax, order.Total });
});

What just happened?

1. We use a guard clause to reject an empty order.
2. We use cross-service validation to check inventory, so we don’t just assume a product is in stock.
3. We calculate tax.
4. We use Entity Framework Core to write the order to a OrdersDb database.
5. And we respond with a 201 Created with the new resource.

How Does Orders Talk to Inventory?

In our new API’s Program.cs, we register an HTTP client:

builder.Services.AddHttpClient<InventoryClient>(client =>
    client.BaseAddress = new Uri("https+http://inventory"));

The URI looks a little funky: notice the scheme (https+http) and the host (inventory).

• https+http tells Aspire’s resolver to try HTTPS first, then fall back to HTTP.
• As you likely noticed, inventory isn’t a DNS name. It’s the canonical service name we’ll define in the AppHost.

If you remember, we defined it earlier:

var inventoryApi = builder.AddProject<Projects.Api>("inventory")
    .WithReference(inventoryDb)
    .WithReference(cache)
    .WaitFor(inventoryDb);

With this in place, Aspire injects the actual URL via configuration. As a result, we don’t require port numbers, a localhost or environment‑specific configuration. At runtime, Aspire injects two environment variables:

Services__inventory__https = https://localhost:6001
Services__inventory__http  = http://localhost:5001

The resolver swaps the placeholder URI for the real endpoint. Just like that, service discovery handles it all.

Upgrade the Blazor Frontend

Our new service isn’t helpful if our customers can’t see it. Let’s now walk through the three components that showcase the Orders API.

Each component uses typed HttpClient services so they inherit telemetry, resilience and service discovery out of the box.

builder.Services.AddHttpClient<OrdersHttpClient>(client =>
    client.BaseAddress = new Uri("https+http://orders"))
        .AddServiceDiscovery()           
        .AddStandardResilienceHandler();

Order List Page

For an order list, we’re using a paginated grid that lets you click a row for details. It also supports inline deletes without a page refresh.

@page "/orders"
@inject OrdersHttpClient Http
@inject NavigationManager Nav
@inject IJSRuntime JS

<PageTitle>Orders</PageTitle>
<div class="container py-4">
    <div class="d-flex justify-content-between align-items-center mb-3">
        <h1 class="display-6 d-flex gap-2 mb-0">
            <span>🧾</span> Orders
        </h1>
        <button class="btn btn-primary" @onclick="CreateNewOrder">
            ➕ New Order
        </button>
    </div>

    @if (_orders is null)
    {
        <p>Loading…</p>
    }
    else
    {
        <table class="table table-striped">
            <thead class="table-light small text-uppercase">
                <tr>
                    <th>#</th>
                    <th>Date</th>
                    <th>Customer Name</th>
                    <th>Total</th>
                    <th>Delete?</th>
                </tr>
            </thead>
            <tbody>
                @foreach (var o in _orders)
                {
                    <tr style="cursor:pointer"
                        @onclick="@(() => Nav.NavigateTo($"/orders/{o.Id}"))">
                        <td>@o.OrderNumber</td>
                        <td>@o.CreatedUtc.ToString("yyyy-MM-dd")</td>
                        <td>@o.CustomerName</td>
                        <td>@o.Total.ToString("C")</td>
                        <td>
                            <button class="btn btn-sm btn-link text-danger"
                                    title="Delete"
                                    @onclick:stopPropagation
                                    @onclick="() => DeleteOrder(o.Id)">
                                🗑
                            </button>
                        </td>
                    </tr>
                }
            </tbody>
        </table>
    }
</div>

@code {
    private List<OrderSummaryDto>? _orders;

    protected override async Task OnInitializedAsync()
        => _orders = (await Http.GetOrdersAsync()).ToList();

    async Task DeleteOrder(Guid id)
    {
        bool ok = await JS.InvokeAsync<bool>("confirm", "Delete this order?");
        if (!ok) return;

        var resp = await Http.DeleteOrderAsync(id);
        if (resp.IsSuccessStatusCode)
        {
            var row = _orders.FirstOrDefault(x => x.Id == id);
            if (row is not null)
            {
                _orders.Remove(row);    
                StateHasChanged();      
            }
        }
        else
        {
            await JS.InvokeVoidAsync("alert", $"Delete failed – {resp.StatusCode}");
        }
    }

    private void CreateNewOrder() => Nav.NavigateTo("/create-order");
}

Here’s the finished Order List page.

Order Details Page

With the Order List page set, we can build an Order Details page. This page displays the full invoice with the line-item pricing pulled directly from the server.

@page "/orders/{Id:guid}"
@inject OrdersHttpClient Http

<h1 class="mb-3">Order @Id</h1>

@if (_order is null)
{
    <p>Loading…</p>
}
else
{
    <p><b>Customer:</b> @_order.CustomerName</p>
    <p><b>Date:</b> @_order.CreatedUtc.ToString("u")</p>

    <table class="table">
        <thead>
            <tr>
                <th>Product</th>
                <th class="text-end">Qty</th>
                <th class="text-end">Line Total</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var l in _order!.Lines)
            {
                <tr>
                    <td>@l.ProductName</td>
                    <td class="text-end">@l.Quantity</td>
                    <td class="text-end">@l.LineTotal.ToString("C")</td>
                </tr>
            }
        </tbody>
        <tfoot>
            <tr><td colspan="2" class="text-end">Subtotal</td><td class="text-end">@_order.Subtotal.ToString("C")</td></tr>
            <tr><td colspan="2" class="text-end">Tax</td><td class="text-end">@_order.Tax.ToString("C")</td></tr>
            <tr class="fw-bold"><td colspan="2" class="text-end">Total</td><td class="text-end">@_order.Total.ToString("C")</td></tr>
        </tfoot>
    </table>
}

@code {
    [Parameter] public Guid Id { get; set; }
    private OrderDetailDto? _order;

    protected override async Task OnParametersSetAsync()
        => _order = await Http.GetOrderAsync(Id);
}

We can then easily view a breakdown of an order:

Create Order Page

We also built a friendly form that queries the Inventory API for the guitar catalog, lets the user order multiple line items and then calculates the totals client-side.

@page "/create-order"
@using Entities
@inject InventoryHttpClient Inventory
@inject OrdersHttpClient    Orders
@inject NavigationManager   Nav
@inject IJSRuntime          JS

<PageTitle>Create Order</PageTitle>

@if (_guitars is null)
{
    <p class="m-4">Loading catalog…</p>
    return;
}

<div class="container py-4" style="max-width:720px">
    <h1 class="display-6 mb-4">➕ Create Order</h1>
    <div class="mb-3">
        <label class="form-label fw-semibold">Customer name</label>
        <InputText @bind-Value="_customerName" class="form-control" />
    </div>
    <EditForm Model="_draft" OnValidSubmit="AddLine">
        <div class="row g-2 align-items-end">
            <div class="col-7">
                <label class="form-label">Product</label>
                <InputSelect TValue="Guid?" @bind-Value="_draft.ProductId" class="form-select">
                    <option value="">‒ select guitar ‒</option>
                    @foreach (var g in _guitars)
                    {
                        <option value="@g.Id">
                            @($"{g.Brand} {g.Model} — {g.Price:C}")
                        </option>
                    }
                </InputSelect>
            </div>
            <div class="col-2">
                <label class="form-label">Qty</label>
                <InputNumber @bind-Value="_draft.Quantity" class="form-control" min="1" max="10" />
            </div>
            <div class="col-3 text-end">
                <label class="form-label invisible">btn</label>
                <button class="btn btn-outline-primary w-100" disabled="@(!_draft.IsValid)">
                    Add
                </button>
            </div>
        </div>
    </EditForm>

    @if (_lines.Any())
    {
        <table class="table table-sm table-hover my-4">
            <thead class="table-light small text-uppercase">
                <tr>
                    <th>Product</th>
                    <th class="text-end">Qty</th>
                    <th class="text-end">Line&nbsp;Total</th>
                    <th></th>
                </tr>
            </thead>
            <tbody>
                @foreach (var l in _lines)
                {
                    var g = _guitarsById[l.ProductId];
                    <tr>
                        <td>@g.Brand @g.Model</td>
                        <td class="text-end">@l.Quantity</td>
                        <td class="text-end">@((g.Price * l.Quantity).ToString("C"))</td>
                        <td class="text-end">
                            <button class="btn btn-sm btn-link text-danger"
                                    @onclick="() => RemoveLine(l)">
                                ✖
                            </button>
                        </td>
                    </tr>
                }
            </tbody>
        </table>
        <div class="text-end mb-3">
            <div>Subtotal: <strong>@_subtotal.ToString("C")</strong></div>
            <div>Tax (5 %): <strong>@_tax.ToString("C")</strong></div>
            <div class="fs-5">Total: <strong>@_total.ToString("C")</strong></div>
        </div>
        <button class="btn btn-success" @onclick="SubmitOrder">Submit Order</button>
    }
</div>

@code {
    private IReadOnlyList<GuitarDto>? _guitars;
    private Dictionary<Guid, GuitarDto> _guitarsById = new();
    private readonly List<CreateOrderLine> _lines = [];
    private readonly LineDraft _draft = new();
    private string _customerName = "Web Customer";

    private decimal _subtotal, _tax, _total;

    protected override async Task OnInitializedAsync()
    {
        _guitars = await Inventory.GetGuitarsAsync();
        _guitarsById = _guitars.ToDictionary(g => g.Id);
    }

    void AddLine()
    {
        if (!_draft.IsValid) return;

        _lines.Add(new CreateOrderLine(_draft.ProductId!.Value, _draft.Quantity));
        _draft.Reset();
        RecalcTotals();
    }

    void RemoveLine(CreateOrderLine l)
    {
        _lines.Remove(l);
        RecalcTotals();
    }

    void RecalcTotals()
    {
        _subtotal = _lines.Sum(l => _guitarsById[l.ProductId].Price * l.Quantity);
        _tax      = Math.Round(_subtotal * 0.05m, 2);
        _total    = _subtotal + _tax;
    }

    async Task SubmitOrder()
    {
        var req  = new CreateOrderRequest(_customerName, _lines);
        var resp = await Orders.SubmitOrderAsync(req);

        if (resp.IsSuccessStatusCode)
            Nav.NavigateTo("/orders");
        else
            await JS.InvokeVoidAsync("alert", $"Order failed – {resp.StatusCode}");
    }

    private class LineDraft
    {
        public Guid? ProductId { get; set; }
        public int   Quantity  { get; set; } = 1;

        public bool IsValid => ProductId.HasValue && Quantity > 0;

        public void Reset()
        {
            ProductId = null;
            Quantity  = 1;
        }
    }
}

Here’s our new Create Order page.

With these three Razor components in place, the UI now consumes the full Orders API—and, transitively, the Inventory API—all without hard-coding a single URL.

Checking In on the AppHost

With our new service in place, let’s orchestrate them. Let’s look at the final Program.cs for the AppHost project:

var builder = DistributedApplication.CreateBuilder(args);

var password = builder.AddParameter("password", secret: true);
var server = builder.AddSqlServer("server", password, 1433)
        .WithDataVolume("guitar-data")
        .WithLifetime(ContainerLifetime.Persistent);

var inventoryDb = server.AddDatabase("guitardb");
var orderDb = server.AddDatabase("ordersdb");

var cache = builder.AddRedis("cache")
            .WithRedisInsight()
            .WithLifetime(ContainerLifetime.Persistent);

var inventoryApi = builder.AddProject<Projects.Api>("inventory")
    .WithReference(inventoryDb)
    .WithReference(cache)
    .WaitFor(inventoryDb);

var ordersApi = builder.AddProject<Projects.OrdersApi>("orders")
        .WithReference(orderDb)
        .WithReference(inventoryApi)
        .WaitFor(orderDb);  

builder.AddProject<Projects.Frontend>("frontend")
    .WithReference(inventoryApi)
    .WithReference(ordersApi)
    .WaitFor(inventoryApi)
    .WaitFor(ordersApi)
    .WithExternalHttpEndpoints();

builder.Build().Run();

When you run the project through AppHost, the orchestrator spins up SQL Server, the Inventory API and the Orders API—all in the correct order.

Each project receives environment variables pointing at its dependencies. Because we called AddServiceDefaults in both our APIs, they automatically read these variables.

For example, the inventory service reads ConnectionStrings__guitardb to configure EF Core, and the orders service reads Services__inventory__https to configure its HTTP client.

With multiple services, the built-in health endpoints are even more important. Our AppHost uses these endpoints to decide when a service is ready. If the inventory service fails its health probe, the orders service waits until it is healthy. If a downstream call repeatedly fails, the circuit breaker configured by AddServiceDefaults prevents overwhelming the dependency.

Observing the End‑to‑end Flow

Let’s fire up our full solution and observe what happens. From the terminal, run:

dotnet run --project GuitarShop.AppHost

Aspire builds each project, creates a SQL Server container, launches the inventory and orders services, and opens the Developer Dashboard. On the Resources page you’ll see what we’ve built so far.

Clicking on orders reveals its environment variables—notice the Services__inventory entry pointing to the actual endpoints.

Let’s place an order from the frontend. Open the Traces tab and you’ll see a span for the incoming POST /orders request, a child span for the outgoing GET /guitars/{id} call to inventory. This confirms that our instrumentation is working—the entire chain is captured and visualized.

Wrapping Up (And What’s Next)

In this post, things got real: we added our first real orchestration scenario to Dave’s Guitar Shop. We built a new orders service alongside our existing inventory service, used Aspire’s service defaults to add telemetry and resilience, and orchestrated everything through the AppHost. The AppHost now declares separate databases for inventory and orders, and injects connection strings into the services.

In the final part of this series, we’ll take our project of our laptops and to the cloud. We’ll see how Aspire’s Azure Container Apps integration maps our SQL and Redis resources to Azure offerings and how the same AppHost definition can be used to deploy our entire guitar shop with a single az containerapp up command.

Stay tuned and see you soon!

This is the fourth part of a six-part exploratory series on .NET Aspire.

• Part 1: What is .NET Aspire?
• Part 2: Exploring the Developer Dashboard
• Part 3: Service Defaults
• This post (Part 4): Integrations
• Part 5: Orchestration and Service Discovery
• Part 6: Deployment using Azure Container Apps

Hello again, friends.

In the first three installments of this .NET Aspire series, we did the following:

• Said hi to .NET Aspire and saw how its opinionated approach removes a ton of cloud-native pain.
• Fired up the Developer Dashboard to watch traces, logs and metrics without juggling terminal windows.
• Met Service Defaults and learned how a single extension method sprinkles telemetry, health checks and resilience across every project.

Today we’ll turn infrastructure into C# code. We’ll grab my hacked-together SQL Server container out of Docker Compose, drop it into Aspire and speed up reads with a Redis cache. Both resources spin up, wire up and light up in the dashboard. No port-mapping gymnastics required.

Enough talk! Bring on the code.

Add a Containerized SQL Server to .NET Aspire

My SQL Server container works in Docker Compose but it’s a second-class citizen. By inviting it to Aspire, we get:

• A shared toolchain: We use one AppHost, one launch profile and one CI pipeline.
• No extra docker compose up step: Hit F5 (or dotnet run) and SQL starts with everything else.
• Automatic health probes, discovery and secrets: Service Defaults injects connection strings and OTLP endpoints for us.
• Native observability: Logs, traces and metrics flow straight to the developer dashboard.

Add SQL Server as an Aspire Resource

To get this party started, let’s navigate to our AppHost project and update Program.cs. After you review the code, we’ll walk through it in detail.

var builder = DistributedApplication.CreateBuilder(args);

var password = builder.AddParameter("password", secret: true);
var server = builder.AddSqlServer("server", password, 1433)
        .WithDataVolume("guitar-data")
        .WithLifetime(ContainerLifetime.Persistent);

var db = server.AddDatabase("guitardb");

var api = builder.AddProject<Projects.Api>("api")
    .WithReference(db)
    .WaitFor(db);

// The following code is the same as before
builder.AddProject<Projects.Frontend>("frontend")
    .WithReference(api)
    .WaitFor(api)
    .WithExternalHttpEndpoints();

builder.Build().Run();

Securely Capture Secrets

In this example:

var password = builder.AddParameter("password", secret: true);

AddParameter creates a parameter resource. When we set the secret parameter to true, we tell Aspire to treat the value like a secret and makes it easy to override with an environment variable or user secrets during local development.

In our secrets.json (or appsettings.json), I read it in using the following structure:

{
  "Parameters": {
    "password": "Dave#123"
  }
}

Obviously, this is only suitable for local development. When deploying to servers, you’ll want a better security model like Azure Key Vault. In that case, you can update your code to the following:

var keyVault = builder.AddAzureKeyVault("key‑vault");
builder.Configuration.AddAzureKeyVaultSecrets("key‑vault");   

var sqlPassword = builder.AddParameter("sql-password", secret: true);

Spin Up a SQL Server with Storage

For this example:

var server = builder.AddSqlServer("server", password, 1433)
        .WithDataVolume("guitar-data")
        .WithLifetime(ContainerLifetime.Persistent);

What just happened?

• AddSqlServer pulls the official mcr.microsoft.com/mssql/server:2022-latest image, sets SA_PASSWORD to our password, and maps it to port 1433.
• WithDataVolume("guitar-data") mounts a named Docker volume so our container survives rebuilds.
• Finally, WithLifetime(ContainerLifetime.Persistent) tells Aspire to reuse the same instance between runs. This avoids slow startup times and having to run migrations every time.

Adding the Database

This one-liner …

var db = server.AddDatabase("guitardb");

… is syntactic sugar for writing a CREATE DATABASE guitardb command when we first launch, and also generates a strongly typed connection string resource. That connection string can now be referenced by any project that needs it.

We’ve added the database, but it’s empty and we need to seed it. Starting with Aspire 9.2, you can use the WithCreationScript method.

With a script (or set of scripts) in hand, make sure you’re copying it to the AppHost output directory by adding this to your project file:

<ItemGroup>
  <None Include="..\Api\data\createdb.sql" Link="createdb.sql">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </None>
</ItemGroup>

We can now update the AppHost’s Program.cs database code to the following.

var password = builder.AddParameter("password", secret: true);
var server = builder.AddSqlServer("server", password, 1433)
        .WithDataVolume("guitar-data")
        .WithLifetime(ContainerLifetime.Persistent);

var scriptPath = Path.Join(Path.GetDirectoryName(typeof(Program).Assembly.Location), "createdb.sql");
var db = server.AddDatabase("guitardb").WithCreationScript(File.ReadAllText(scriptPath));

This is just one of many ways you can see data. To learn more, read the Microsoft Docs.

Register the API with the Database

Finally, this code registers the API to the database.

var api = builder.AddProject<Projects.Api>("api")
    .WithReference(db)
    .WaitFor(db);

The WithReference(db) injects two things into the container:

• The connection string as ConnectionStrings__guitardb
• The health-probe address for the SQL container so your app knows when the database is up

The WaitFor(db) line means Aspire won’t even docker run the API until SQL Server reports it as healthy.

Update the Inventory API

Because we already rely on Service Defaults, the API can pick up builder.Configuration.GetConnectionString("db") automatically. The only code we need to touch is making sure EF Core is registered to use the database in the API project’s Program.cs:

builder.Services.AddSqlServer<GuitarStoreContext>("guitardb");

That single line allows the AppHost project to spin up the SQL Server container and inject its connection string into the API at launch. Service Defaults then wires up logging, tracing, metrics and resilience. As a result, the AddSqlServer<GuitarStoreContext>("guitardb") call grabs the injected connection string, registers the DbContext and plugs into our observability out of the box.

Examine the Dashboard

When we fire up the app, we now see the database up and running alongside our app.

If we review the details of the API resource, we see the injected connection string, too.

Our telemetry lights up: if we browse to our traces, we can see a request end-to-end.

Our database is officially out of Docker Compose and into Aspire! We can now delete the old docker-compose.yml and use SQL Server alongside the rest of our project with a single F5 command (or dotnet run).

We can now move onto our Redis integration to speed up our reads.

Adding Redis for Lightning-fast Caching

Our /guitars endpoint is read-heavy. To make it lightning-fast (and to avoid round-trips to the database), we’ll add Redis as a cache layer and let Aspire wire things up.

To wire Redis in AppHost, we’ll add this right after the SQL snippet.

var cache = builder.AddRedis("cache")
                   .WithRedisInsight()
                   .WithLifetime(ContainerLifetime.Persistent);

What happens here? We pull a Redis container from docker.io/library/redis that helps to avoid any local installs or port wrangling. We also get a PING health probe that is viewable from the /health endpoint and the developer dashboard.

Then, the connection string ConnectionStrings:cache gets injected automatically into any project that calls WithReference(cache).

Optionally, we can also include our favorite Redis admin UI, as Aspire supports Redis Insight or Redis Commander. I’ve added Redis Insight. When I do so, Aspire grabs docker.io/redis/redisinsight to allow me to easily work with my Redis instance.

Much like with our SQL Server container, we add .WithLifetime(ContainerLifetime.Persistent) to tell Aspire, “Don’t tear down the container when I stop debugging.” The result is much faster start-ups and durable state between sessions—great for day-to-day development, demos or long-running background jobs. If you ever need a clean slate, you can still prune the container manually or switch the lifetime back to the default ContainerLifetime.Transient mode.

Here’s my entire Program.cs in AppHost:

var builder = DistributedApplication.CreateBuilder(args);

var password = builder.AddParameter("password", secret: true);
var server = builder.AddSqlServer("server", password, 1433)
        .WithDataVolume("guitar-data")
        .WithLifetime(ContainerLifetime.Persistent);

var db = server.AddDatabase("guitardb");

var cache = builder.AddRedis("cache")
            .WithRedisInsight()
            .WithLifetime(ContainerLifetime.Persistent);

var api = builder.AddProject<Projects.Api>("api")
    .WithReference(db)
    .WithReference(cache)
    .WaitFor(db);

builder.AddProject<Projects.Frontend>("frontend")
    .WithReference(api)
    .WaitFor(api)
    .WithExternalHttpEndpoints();

builder.Build().Run();

Update Our API to Use Redis

How do we update the API to use Redis? Let’s sprinkle some minimal caching over the GET /guitars endpoint. After installing the StackExchange.Redis package, we can add a decorator to use output caching.

app.UseOutputCache();

app.MapGet("/guitars",
   [OutputCache(Duration = 30)] async (GuitarStoreContext db) =>
       await db.Guitars
               .OrderBy(g => g.Brand).ThenBy(g => g.Model)
               .Select(g => new { g.Id, g.Brand, g.Model, g.Series, g.Price, g.SalePrice })
               .ToListAsync());

The output caching middleware can now intercept requests after Aspire registers the Redis store. For testing, we are using a 30-second TTL, but once we go live we can adjust it through configuration.

Let’s now run the solution and open the dashboard. Our resources keep building up.

If we browse to our Redis Insight URL, we can see the cache!

When we fire off some calls, we now see an end-to-end request completing in under 3.43ms. Not bad!

With SQL Server and Redis in play, our dashboard now shows a dependency graph pointing to both SQL and Redis nodes.

Developers Are Happy

Before Aspire (and Docker containers), can you imagine all the work getting a new developer access to a local environment with multiple APIs, logging, a SQL server and a Redis instance?

Now, here’s all we need to do:

git clone https://github.com/davesguitarshop
cd inventory
dotnet run --project GuitarShop.AppHost

With one single command we restore NuGet packages, build projects, start our SQL Server and Redis containers, launch our dashboard and open a browser tab at https://localhost:5001. No SQL installations, no docker compose up and no “What ports do we need to use again?” What a world.

A Sneak Peek: Getting to the Cloud

While developer happiness is huge, the real payoff comes when we push up to the cloud—to Azure Container Apps, for example. Because the same AppHost definition travels with us, the pipeline only needs:

az containerapp up \
  --name guitar-shop \
  --resource-group guitar-shop-rg \
  --subscription guitar-shop-prd

YAML

As a result, Aspire’s Azure Container App extension will map:

• AddSqlServer - Azure SQL (or bring your own image)
• AddRedis - Azure Cache for Redis (or your own image)
• Health probes - Kubernetes-style liveness and readiness endpoints
• OTLP - Azure Monitor / AppInsights

We will have much more in Part 6—stay tuned!

Wrapping Up (And What’s Next)

We just replaced a huge docker-compose.yml, a half‑dozen environment‑variable gymnastics and a README full of “run this before that” commands with just a few lines of C#—all discoverable from IntelliSense. Are you not entertained?

Key takeaways:

• Integrations are resources, not chores. After declaring intent with AddSqlServer and AddRedis, Aspire handles images, ports and health.
• Connection strings flow automatically.
• Observability is built in. Every query, cache hit and exception shows up in the dashboard with zero extra code.
• Local developer setup is trivial. New devs run one command and start coding.
• Portability. The same AppHost definition deploys to Azure Container Apps, AKS or Docker Swarm with minimal tweaks.

In Part 5, we’ll dive into service discovery and orchestration—how Aspire lets services talk to each other without hard‑coding URLs and how Polly policies keep things resilient when the network gets mad.

Until then, happy coding and see you soon!

This is the third part of a six-part exploratory series on .NET Aspire.

• Part 1: What Is .NET Aspire?
• Part 2: Exploring the Developer Dashboard
• This post (Part 3): Service Defaults
• Part 4: Integrations
• Part 5: Orchestration and Service Discovery
• Part 6: Deployment using Azure Container Apps

In the first installment of this series, we said hi to .NET Aspire, Microsoft’s opinionated toolkit for building cloud-ready applications. In the sequel, we peeked at the Developer Dashboard to show how we can add observability with zero extra code.

Now, we want to answer the following question from your boss: “How do we make every service in our solution have consistency without having to copy and paste hundreds of lines of boilerplate into every project?”

“It depends” won’t get you out of this one, friend. The answer lies with Aspire’s service defaults. With it, you can attach a single builder.AddServiceDefaults() to your app and it immediately receives:

• OpenTelemetry tracing, logging and metrics wired to your favorite exporter
• Health-check endpoints that distinguish “alive” from “ready”
• Service discovery so in-cluster, service-to-service calls work without hard-coded URLs
• An opinionated Polly-powered resilience pipeline with time-outs, retries and circuit breakers

Let’s get started, shall we?

Why Bother with Service Defaults?

As we discussed in our first post, building services can get quite complicated with you having to sprinkle logging, tracing, retries, Docker configs, health checks and whatever else you need.

With .NET Aspire’s premise to be cloud-ready by default, you can instead reference ServiceDefaults once and instantly have an opinionated baseline that works the same everywhere, whether it’s on your laptop or inside Azure Container Apps. These conventions are tightly coupled with integrations that spin up the infrastructure you need (like SQL Server, Redis and Key Vault)—all with a single line of C#!

Everything is then expressed as C# code inside your AppHost project, so you can version control your application’s topology just like application logic.

Since conventions are expressed in one location, a future change—like changing from Honeycomb to Azure Monitor—is a one-line edit.

Let’s now look at some code and see how it all works.

Looking Inside the ServiceDefaults Project

When you create a new Aspire app, or add Aspire to your existing solution, you’ll see a project named ServiceDefaults.

Let’s look in the ServiceDefaults project. Open the file Extensions.cs (or something similar). You should see an AddServiceDefaults extension method that looks something like this:

public static TBuilder AddServiceDefaults<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
{
    builder.ConfigureOpenTelemetry();
    builder.AddDefaultHealthChecks();
    builder.Services.AddServiceDiscovery();
    builder.Services.ConfigureHttpClientDefaults(http =>
    {
        http.AddStandardResilienceHandler();
        http.AddServiceDiscovery();
    });

    return builder;
}

Let’s unpack this code.

Note: The resiliency and service discovery parts deserve a treatment of their own and will be discussed in detail in Part 5 of our series.

OpenTelemetry Configuration

When we look at builder.ConfigureOpenTelemetry, .NET Aspire provides a set of opinionated defaults for OpenTelemetry.

By default, Aspire adds:

These are all viewable from the Aspire dashboard that we reviewed in the previous post. For the OTLP exporter, it easily integrates with your telemetry. For example, in Azure Container Apps the exporter points at Azure Monitor.

None of this is magic. If you scroll down in your Extensions.cs, you can inspect the ConfigureOpenTelemetry extension method to learn more.

public static TBuilder ConfigureOpenTelemetry<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
{
    builder.Logging.AddOpenTelemetry(logging =>
    {
        logging.IncludeFormattedMessage = true;
        logging.IncludeScopes = true;
    });

    builder.Services.AddOpenTelemetry()
        .WithMetrics(metrics =>
        {
            metrics.AddAspNetCoreInstrumentation()
                .AddHttpClientInstrumentation()
                .AddRuntimeInstrumentation();
        })
        .WithTracing(tracing =>
        {
            tracing.AddSource(builder.Environment.ApplicationName)
                .AddAspNetCoreInstrumentation()
                // Uncomment the following line to enable gRPC instrumentation (requires the OpenTelemetry.Instrumentation.GrpcNetClient package)
                //.AddGrpcClientInstrumentation()
                .AddHttpClientInstrumentation();
        });

    builder.AddOpenTelemetryExporters();

    return builder;
}

Configuring your exporter is super easy. Because the exporter URL comes from OTEL_EXPORTER_OTLP_ENDPOINT, changing where telemetry flows is an easy one-liner:

export OTEL_EXPORTER_OTLP_ENDPOINT=https://api.honeycomb.io

In the AddOpenTelemetryExporters, you’ll see it in action. Need Azure Monitor instead? Uncomment the relevant block in AddOpenTelemetryExporters, supply an APPLICATIONINSIGHTS_CONNECTION_STRING, and call it a day.

private static TBuilder AddOpenTelemetryExporters<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
{
    var useOtlpExporter = !string.IsNullOrWhiteSpace(builder.Configuration["OTEL_EXPORTER_OTLP_ENDPOINT"]);

    if (useOtlpExporter)
    {
        builder.Services.AddOpenTelemetry().UseOtlpExporter();
    }

    // Uncomment the following lines to enable the Azure Monitor exporter (requires the Azure.Monitor.OpenTelemetry.AspNetCore package)
    //if (!string.IsNullOrEmpty(builder.Configuration["APPLICATIONINSIGHTS_CONNECTION_STRING"]))
    //{
    //    builder.Services.AddOpenTelemetry()
    //       .UseAzureMonitor();
    //}

    return builder;
}

Default Health Checks

Moving on: What does builder.AddDefaultHealthChecks() get us? This powerful line adds a set of opinionated defaults for health checks, which can be used by systems and applications to see if your app is ready.

The AddDefaultHealthChecks method adds a default liveness check to check if the application is responsive.

public static TBuilder AddDefaultHealthChecks<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
{
    builder.Services.AddHealthChecks()
        // Add a default liveness check to ensure app is responsive
        .AddCheck("self", () => HealthCheckResult.Healthy(), ["live"]);

    return builder;
}

You can see how this all works in the MapDefaultEndpoints extension method, where it exposes a /health endpoint and an /alive endpoint. The /health endpoint illustrates if the app is running and ready to receive requests. The /alive endpoint indicates if the app is running or must be restarted because of a crash.

public static WebApplication MapDefaultEndpoints(this WebApplication app)
{
    // Adding health checks endpoints to applications in non-development environments has security implications.
    // See https://aka.ms/dotnet/aspire/healthchecks for details before enabling these endpoints in non-development environments.
    if (app.Environment.IsDevelopment())
    {
        // All health checks must pass for app to be considered ready to accept traffic after starting
        app.MapHealthChecks("/health");

        // Only health checks tagged with the "live" tag must pass for app to be considered alive
        app.MapHealthChecks("/alive", new HealthCheckOptions
        {
            Predicate = r => r.Tags.Contains("live")
        });
    }

    return app;
}

As you can see the defaults are for development only. You must opt into production exposure.

The health checks also come built in with Aspire’s various integrations. For example, the health check for SQL Server verifies that SQL Server is running and that a connection can be established.

Create a Custom Service Defaults Project

If you look at the MyApp.ServiceDefaults.csproj, you’ll notice a FrameworkReference dependency on Microsoft.AspNetCore.App.

<FrameworkReference Include="Microsoft.AspNetCore.App" />

That reference brings in the entire ASP.NET Core shared framework (with Kestrel, MVC, SignalR and so on).

In certain situations, you might not want this:

• Non-HTTP workloads: Background workers or queue processors don’t need Kestrel.
• Serverless hosts: Azure Functions ships their own ASP.NET Core copy. A second copy can cause binding conflicts.
• Reusable class libraries: Transitive framework references force consumer apps to carry ASP.NET Core. What if the library is UI-agnostic?

In that case, you can create a custom service defaults project. According to the Microsoft Docs, you can create a new class library project and add its dependencies to the project file. Check out the docs for more information.

Wrapping Up

Service Defaults are the unsung hero of .NET Aspire. They compress all the OpenTelemetry wiring, health probes, discovery and Polly policies into one method call. As a result, every service behaves predictably, telemetry is always on and your new hire ramps up quickly (think minutes, not days).

In the next installment we’ll explore integrations. We’ll see how Aspire spins up SQL Server and Redis containers—all orchestrated from our AppHost. Stay tuned!

This is the second part of a six-part exploratory series on .NET Aspire.

• Part 1: What Is .NET Aspire?
• This post (Part 2): Exploring the Developer Dashboard
• Part 3: Service Defaults
• Part 4: Integrations
• Part 5: Orchestration and Service Discovery
• Part 6: Deployment Using Azure Container Apps

Hello again, friends, and welcome back. If you missed the intro to about .NET Aspire, feel free to check that out before reading the rest of this piece. Today, we’ll focus on my favorite feature: the developer dashboard. The dashboard allows you to track your app in real-time through a single user interface.

Before we get there, I want to first walk you through the project we’ll be using: Dave’s Guitar Shop. If you remember, here’s the initial high-level architecture of my Aspire-less solution.

Exploring the Project

For this post, we’ll be focusing on the /inventory API. This API is consumed by a Blazor server-side web app. I’ll walk you through key parts of the solution.

The API Code

We are using a quick ASP.NET Core Minimal API with basic CRUD (create, read, update, delete) operations. The data is persisted to a containerized SQL server and uses Entity Framework for query-ability.

Here’s a sample of the API calls:

app.MapGet("/guitars", async (GuitarStoreContext db) =>
{
    var list = await Queries.GetAllGuitars(db).ToListAsync();
    return Results.Ok(list);
});

app.MapGet("/guitars/{id:guid}", async (Guid id, GuitarStoreContext db) =>
    await Queries.GetGuitarById(db, id) is { } dto
        ? Results.Ok(dto)
        : Results.NotFound());

app.MapPost("/guitars", async (Guitar guitar, GuitarStoreContext db) =>
{
    db.Guitars.Add(guitar);
    await db.SaveChangesAsync();
    return Results.Created($"/guitars/{guitar.Id}", guitar);
});

app.MapPut("/guitars/{id:guid}", async (Guid id, Guitar updated, GuitarStoreContext db) =>
{
    var guitar = await db.Guitars.FindAsync(id);
    if (guitar is null) return Results.NotFound();

    db.Entry(guitar).CurrentValues.SetValues(updated);
    await db.SaveChangesAsync();
    return Results.NoContent();
});

app.MapDelete("/guitars/{id:guid}", async (Guid id, GuitarStoreContext db) =>
{
    var guitar = await db.Guitars.FindAsync(id);
    if (guitar is null) return Results.NotFound();

    db.Guitars.Remove(guitar);
    await db.SaveChangesAsync();
    return Results.NoContent();
});

The Database

From the SQL side, my Dockerfile is using the mcr.microsoft.com/mssql/server:2022-latest image. If you’re interested in learning more, check out the Microsoft documentation. Right now, I’m using Docker Compose to manage the container.

In the next post, we’ll discuss how to simplify this with .NET Aspire.

The Blazor App

Finally, this API is consumed by a Blazor web app. For now, we’ll show the main component where we load all the guitars in inventory.

@page "/"
@inject BackendHttpClient HttpClient

<PageTitle>Guitars</PageTitle>

<div class="container py-4">
    <h1 class="display-6 mb-4 d-flex align-items-center gap-2">
        <span>🎸</span> Guitar Catalog
    </h1>

    @if (_guitars is null)
    {
        <div class="d-flex align-items-center" aria-label="Loading">
            <div class="spinner-border text-primary me-2" role="status">
                <span class="visually-hidden">Loading…</span>
            </div>
            <span>Loading guitars…</span>
        </div>
    }
    else if (!_guitars.Any())
    {
        <p class="text-muted">No guitars found.</p>
    }
    else
    {
        <div class="card shadow-sm">
            <div class="card-header bg-primary text-white fw-semibold">
                Guitar List
            </div>
            <div class="table-responsive">
                <table class="table table-hover mb-0 align-middle">
                    <thead class="table-light">
                        <tr class="small text-uppercase">
                            <th scope="col">Brand</th>
                            <th scope="col">Model</th>
                            <th scope="col">Series</th>
                            <th scope="col" class="text-end">Price</th>
                        </tr>
                    </thead>
                    <tbody>
                        @foreach (var g in _guitars!)
                        {
                            <tr>
                                <td>@g.Brand</td>
                                <td>@g.Model</td>
                                <td>@g.Series</td>
                                <td class="text-end">@g.Price.ToString("C")</td>
                            </tr>
                        }
                    </tbody>
                </table>
            </div>
        </div>
    }
</div>

@code {
    private List<GuitarDto>? _guitars;

    protected override async Task OnInitializedAsync()
    {
        _guitars = await HttpClient.GetGuitarsAsync();
    }
}

And with that, we have a table that lists everything in inventory.

Adding the Dashboard

Now that we’ve got an app, let’s add some observability to it by using the .NET Aspire dashboard.

Which Dashboard to Choose?

We have two choices: using standalone mode or a .NET Aspire project.

With standalone mode, you can pull a Docker image and use it without the rest of .NET Aspire. Let’s say your Operations team needs a “single pane of glass” for all your services—say, half of your services are in .NET and the rest are in Node or Python.

One single dashboard can ingest everyone’s OpenTelemetry (OTLP) traffic without worrying about who wrote the code. Additionally, it can run as its own container or deployment and stay up even if your app crashes.

We’ll be using the built-in Aspire dashboard. This shines during our inner-loop process: change code, hit F5 in Visual Studio and watch the traces. That way, the dashboard appears automatically and is wired to every container, project and secret we know about.

With that in mind, we’ll start to Aspire-ify our project.

Add Aspire to Our Existing Application

There are many ways to add Aspire to an existing app; for us, we’ll do it through Visual Studio tooling.

In Visual Studio, let’s create a new project and search for the .NET Aspire App Host template.

Once you add the project, you’ll see two new projects added to Solution Explorer: an AppHost project and a ServiceDefaults library project. Let’s talk about the AppHost project (we will cover ServiceDefaults in detail in our next post).

The AppHost Project

We can think of AppHost as a command center for our application. Instead of juggling a bunch of configs, Docker Compose files and scripts, this project has a single launch profile that boots our app and its dependencies with access to one fully wired dashboard.

By default, the file includes these two lines that really pack a punch:

var builder = DistributedApplication.CreateBuilder(args);
builder.Build().Run();

This code scans every referenced project or container image, builds a dependency graph, injects environment variables (like connection strings and secrets), and launches the .NET Aspire dashboard.

How does it all work?

1. AppHost starts.
2. For each project, it runs with a generated launch command.
3. It runs docker run behind the scenes for each container.
4. It sets environment variables like Api__BaseAddress and ConnectionStrings__DefaultConnection.
5. The service defaults (to be discussed next time!) discover the dashboard endpoint at OTEL_EXPORTER_OTLP_ENDPOINT.
6. You have a glorious dashboard to use out of the box.

Before we launch the app and see it in action, let’s add a few lines of code to our AppHost project.

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.Api>("api");

builder.AddProject<Projects.Frontend>("frontend")
    .WithReference(api)
    .WaitFor(api)
    .WithExternalHttpEndpoints();

builder.Build().Run();

From a high level, here’s what happens:

1. DistributedApplication.CreateBuilder(args) creates a builder that will handle every service, container and config value.
2. AddProject<Projects.Api>("api") tells the builder to spin up the API container and have it addressable as api for other services to reference.
3. For the frontend, AddProject<Projects.Frontend>("frontend") registers the UI and WithReference(api) hands the UI the API’s base URL. Then, WaitFor(api) makes the UI wait until the API is healthy. Finally, WithExternalHttpEndpoints() exposes the UI so a browser can reach it.

There is much, much more we can (and will!) do here, but for now, this will help us “connect” the UI with the API in our dashboard.

Enough already! Let’s see it.

The Dashboard in Action

Right away, we see a unified interface for our application. Here you can easily navigate to our services and quickly access logs, traces and metrics in one spot.

If we click over to the Console section, you can select from the api or frontend logs. No more painful toggling between multiple consoles!

We have structured logging that allows us to easily filter on what we need, like a SQL command:

With traces, we can run through our dependencies and how long they take. For now, we can see details of the HTTP request and the SQL call.

We also have pre-baked metrics and a dependency graph (which will get more interesting over this series, I promise).

If you click api, you can get information on health checks and the environment variables Aspire uses.

There are many more features I don’t have space to cover, like: dashboard authentication, metrics and GitHub Copilot integration. I’d suggest building a new Aspire project and clicking around for yourself. I don’t think I can go back to local debugging and tracing before Aspire.

Wrapping Up

I hope you enjoyed learning more about the .NET Aspire doashboarding capabilities. Next time, we’ll work on integrations and smart defaults, where we can add our SQL Server container with just a few lines of code.

See you there, and happy coding!

This is the first part of a six-part exploratory series on .NET Aspire.

• This post (part 1): What Is .NET Aspire?
• Part 2: Exploring the Developer Dashboard
• Part 3: Service Defaults
• Part 4: Integrations
• Part 5: Orchestration and Service Discovery
• Part 6: Deployment Using Azure Container Apps

Over the last few years, I’ve been chronically tired and I don’t know why. I hydrate, I exercise, I get decent sleep and I even eat a vegetable or two. In short, I’m Wisconsin healthy. (85% healthy habits, and 15% cheese curds and beer.)

I haven’t been able to figure out what’s wrong, and the doctors haven’t either. But after much reflection and some late nights, I figured it out.

I work in cloud-native development.

Progress, Albeit Slow

Once upon time—a simpler time, no doubt—we shipped hulking monoliths. One app, one deploy and one big, beautiful ball of code. Need to add a feature? Crack open the behemoth, sprinkle in a few classes and pray the whole thing still compiles on Friday afternoon.

Then came microservices and our “make everything smaller” movement. Suddenly that single code pile shattered into a mess of bite-sized services, each with its own repo, pipeline and database. Debugging turned into a game of distributed whack-a-mole, all scattered across 12 clusters like digital confetti.

Deploying code used to be “copy files to the server.” Today it’s a helm upgrade, a Docker registry push, a secret rotation, configuration updates and a moment of silence for the build agent. Progress? Absolutely. Simple and enjoyable? Never.

Gains ... And Gains

But here’s the thing: The chaos isn’t for nothing. We’ve gained on-demand infrastructure, independent deployments and self-healing resilience that would make past Dave weep. Spinning up a replica database takes minutes, not days. Rolling back a troubled service is a one-line re-deploy, not an all-hands war room.

Those wins are real—but so is the cognitive load. Every new repo adds another Dockerfile, another liveness probe and another chance to typo your configuration files. Wouldn’t it be nice to keep the benefits without the YAML-induced migraines?

Imagine an opinionated set of tools that wrap all those best practices—service discovery, health checks, telemetry, secret management and more—into sane defaults you don’t have to wire up from scratch. Something that spins up your entire stack with a single command, shows traces and logs in one dashboard, and makes production deployment a breeze.

.NET Aspire for Cloud-Native Development

We’ll be looking at .NET Aspire, your building blocks for working with the complexities of cloud-native development. It doesn’t erase the complexity but organizes it into parts that snap together:

• You can bootstrap your app with a single command, and no more Docker Compose gymnastics.
• A unified developer dashboard for distributed tracing, logs, metrics and container monitoring in a single tab. No more having six debugging windows for your frontend and all your APIs.
• Aspire includes smart defaults to cover OpenTelemetry, Polly retries, secret rotation and health probes.
• No more hard-coding URLs with configuring service discovery at development time.
• Component support lets you drop in PostgreSQL, Redis, Azure Service Bus, Key Vault and more with one line of code. Aspire pulls the container image, wires the connection string, adds health probes and even injects secrets for you—all powered by its integration library.

The Project This Series Will Explore

Get comfortable: We’re going to spend the next four posts applying .NET Aspire to an existing application. Welcome to Dave’s Guitar Shop. (If you have free inventory, feel free to pass it my way.)

Dave’s Guitar Shop started as a regular monolithic application. It had a Blazor web app and a single API project that handled identity, product inventory and orders.

Dave’s Guitar Shop is growing and now we have several development teams. We’ve decided to leverage microservices, and our high-level architecture is looking a bit different.

Keep in mind this is just a high-level view! We still want to add telemetry services, some queuing and maybe even some OpenAI services. We’re also having scaling and resiliency issues and want to deploy to Azure Container Apps. This is a great use case for .NET Aspire.

Throughout these next four posts, we’re going to show off the benefits of .NET Aspire. In the next post, I’ll show you how to add .NET Aspire to an existing project and the benefits of the Developer Dashboard. Stay tuned, and I’ll see you soon!

A new AI model has taken the tech world, and the actual world, by storm.

It performs close to, or better than, the GPT 4o, Claude and Llama models. It was developed at a cost of $1.3 billion (rather than the originally reported $6 million)—using clever engineering instead of top-tier GPUs. Even better, it was shipped as open-source, allowing anyone in the world to understand it, download it and modify it.

Have we achieved the democratization of AI, where the power of AI can be in the hands of many and not the few big tech companies who can afford billions of dollars in investment?

Of course, it’s not that simple. After Chinese startup DeepSeek released its latest model, it has disrupted stock markets, scared America’s Big Tech giants and incited TMZ-level drama across the tech space. To wit: Are American AI companies overvalued? Can competitive models truly be built at a fraction of the cost? Is this our Sputnik moment in the AI arms race? (I don’t think NASA was able to fork the Sputnik project on GitHub.)

In a future article, I’ll take a deeper dive into DeepSeek itself and its programming-focused model, DeepSeek Coder. For now, let’s get our feet wet with DeepSeek. Because DeepSeek is built on open source, we can download the models locally and work with them.

Recently, Progress’ own Ed Charbeneau led a live stream on running DeepSeek AI with .NET Aspire. In this post, I’ll take a similar approach and walk you through how to get DeepSeek AI working as he did in the stream.

Note: This post gets us started; make sure to watch Ed’s stream for a deeper dive.

Our Tech Stack

For our tech stack, we’ll be using .NET Aspire. .NET Aspire is an opinionated, cloud-ready stack built for .NET-distributed applications. For our purposes today, we’ll be using it to get up and running quickly and to easily manage our containers. I’m not doing .NET Aspire justice, with all its power and capabilities: Check out the Microsoft documentation to learn more.

Before we get started, make sure you have the following:

• Docker (to get up and running on Docker quickly, Docker Desktop is a great option)
• Visual Studio 2022
• .NET 8 or later
• A basic knowledge of C#, ASP.NET Core and containers

Picking a Model

To run models locally on our system, we’ll be using Ollama, an open-source tool that allows us to run large language models (LLMs) on our local system. If we head over to ollama.com, let’s search for deepseek.

You might be compelled to install deepseek-v3, the new hotness, but it also has a 404 GB download size. Instead, we’ll be using the deepseek-r1 model. It’s less advanced but good enough for testing—it also uses less space, so you don’t need to rent a data center to use it.

It’s a tradeoff between parameter size and download size. Pick the one that both you and your machine are comfortable with. In this demo, I’ll be using 8b, with a manageable 4.9GB download size. Take note of the flavor you are using, as we’ll need to put it in our Program.cs soon.

Set Up the Aspire Project

Now, we can create a new Aspire project in Visual Studio.

1. Launch Visual Studio 2022 and select the Create a new project option.
2. Once the project templates display, search for aspire.
3. Select the .NET Aspire Starter App template, and click Next.

4. Then, click through the prompts to create a project. If you want to follow along, we are using .NET 9.0 and have named the project DeepSeekDemo.
5. Right-click the DeepSeekDemo.AppHost project and click Manage NuGet Packages….
6. Search for and install the following NuGet packages. (If you prefer, you can also do it from the .NET CLI or the project file.)

• CommunityToolkit.Aspire.Hosting.Ollama
• CommunityToolkit.Aspire.OllamaSharp

7. Now that everything is installed, you can navigate to the Program.cs file in that same project and replace it with the following.

var builder = DistributedApplication.CreateBuilder(args);

var ollama = builder.AddOllama("ollama")
                .WithDataVolume()
                .WithGPUSupport()
                .WithOpenWebUI();
builder.Build().Run();

Here’s a breakdown of what the AddOllama extension method does:

• AddOllama adds an Ollama container to the application builder. With that in place, we can add models to the container. These models download and run when the container starts.
• WithDataVolume allows us to store the model in a Docker volume, so we don’t have to continually download it every time.
• If you are lucky enough to have GPUs locally, the WithGPUSupport call uses those.
• The WithOpenWebUI call allows us to talk to our chatbot using the Open WebUI project. This is served by a Blazor front end.

8. Finally, let’s add a reference to our DeepSeek model so we can download and use it. We can also choose to host multiple models down the line.

var builder = DistributedApplication.CreateBuilder(args);

var ollama = builder.AddOllama("ollama")
                .WithDataVolume()
                .WithGPUSupport()
                .WithOpenWebUI(); 

var deepseek = ollama.AddModel("deepseek-r1:8b");

builder.Build().Run();

Explore the Application

Let’s run the application! It’ll take a few minutes for all the containers to spin up. While you’re waiting, you can click over to the logs.

Once all three containers have a state of Running, click into the endpoint for the ollama-openweb-ui container.

Once there, select the DeepSeek model and you’ll be ready to go.

Let’s try it out with a query. For me, I entered an oddly specific and purely hypothetical query—how can a tired parent persuade his daughter to expand musical tastes beyond just Taylor Swift? (Just saying: the inevitable Kelce/Swift wedding will probably be financed by all my Spotify listens.)

You’ll notice right away something you don’t see with many other models: It’s walking you through its thought process before sending an answer. Look for this feature to be quickly “borrowed” by its competitors.

After a minute or two, I’ll have an answer from DeepSeek.

Next Steps

With DeepSeek set up in your local environment, the world is yours. Check out Ed’s DeepSeek AI with .NET Aspire demo to learn more about integrating it and any potential drawbacks.

See also:

• Running DeepSeek locally with Just a Browser live stream with Ed Charbeneau
• Local GenAI Processing: WebLLM with Blazor WebAssembly blog post by Ed

Any thoughts on DeepSeek, AI or this article? Feel free to leave a comment. Happy coding!

Build 2022 took place last week, giving Microsoft developers a lot to get excited about—whether it’s new Azure bells and whistles, Windows development, developer productivity updates, or tons of other content you can view from the session list.

In this article, I’d like to recap three talks that highlighted what’s new in the .NET world—specifically for ASP.NET Core web applications.

• C# 11 Updates
• Output caching in ASP.NET Core 7
• Minimal API updates

Note: This post includes code samples. The samples are subject to minor syntax changes before .NET 7 releases in November 2022.

C# 11 Updates

With .NET pivoting to annual November releases the last few years, the languages are also following suit. With C# 11 development in full swing, Build is always a good time to get a preview of what’s coming. With that in mind, Mads Torgersen led the session, What’s Next in C# 11, to give us a preview of some new features.

Here are a few of them:

• Static abstract members
• Pattern matching updates support list patterns
• Required properties
• Raw string literals

Static Abstract Members

C# 11 will include the ability to add static abstract members in interfaces, where you can include static properties, overloadable operators or other static members. A big use case is with using mathematical operators, and Mads showed off an example.

Imagine you’ve got a quick program that adds all items in a given array and it returns the total (for brevity, this uses top-level statements, which eliminates the need for a Main method):

var result = AddAll(new[] { 1, 2, 3, 4, 5 });
Console.WriteLine(result);

int AddAll(int[] values)
{
    int result = 0;

    foreach (var value in values)
    {
        result += value;
    }
    return result;
}

What if we could have numeric types implement interfaces? That’s what we can do with static abstract members with this modified AddAll method:

T AddAll<T>(T[] values) where T : INumber<T>
{
    T result = T.AdditiveIdentity;

    foreach (var value in values)
    {
        result += value;
    }
    return result;
}

Now, we are taking T, which is any type that implements the INumber<TSelf> interface (int, short, long, float, decimal or any type that represents a number). The interface provides access to APIs like Abs, Min, Max, TryParse and the typical mathematical operators, which in turn allows developers to write code that relies on the interfaces with these abstract members as a constraint.

If you would change the result array to a mix of int and decimal types, it would calculate correctly without having to explicitly declare the specific type, through the beauty of interfaces. For more details on static abstract interfaces check out the Microsoft documentation.

Pattern Matching Updates Support List Patterns

Using the same example that Mads provided, C# 11 provides updates to pattern matching that helps with processing incoming list items. It can greatly simplify things, like in the following example:

T AddAll<T>(T[] values) where T : INumber<T> => values switch
{
    [] => T.AdditiveIdentity,
    [var t1, .. var middle] => t1 + AddAll(middle),
};

Required Properties

Mads also demonstrated something we’ve all been impatiently waiting for: required properties. To illustrate the benefits, let’s build out a trusty Person class:

public class Person 
{
    public string FirstName { get; set; }
    public string MiddleName { get; set; }
    public string LastName { get; set; }
}

To enforce instantiating certain fields, you would need to rely on a constructor-based approach. If you want to enforce a caller to instantiate a FirstName and LastName, there’s not a way to do it with object initialization. For example, what if a developer writes code before their morning coffee and accidentally makes the LastName the MiddleName?

var person = new Person()
{
    FirstName = "Saul",
    MiddleName = "Goodman"
};

With required properties, we can enforce this using object initialization, like so:

public class Person 
{
    public required string FirstName { get; set; }
    public string MiddleName { get; set; }
    public required string LastName { get; set; }
}

In this case, the compiler will throw an error when LastName is not initialized.

I’m tremendously excited for this feature—it was originally slated for C# 10, and is finally here. It really should have been shipped with the nullability features in the past few releases, as developers have used hacky workarounds like = null! to accommodate these situations. With this update, who needs constructors? Not me.

Raw String Literals

Mads also showed off raw string literals. We’ve all dealt with the pain of escaping pesky characters inside our strings, like quotes, double quotes, white space and backslashes. With C# 11, it’s much easier to create multi-line strings, or characters that previously required you to escape them.

According to the documentation, raw string literals:

• Start and end with a sequence of at least three double quote characters ("""). You can also include more than three consecutive characters to support strings that contain three or more repeated quotes characters.
• Single-line raw string literals require the opening and closing quote characters on the same line and multi-line raw string literals require both opening and closing quote characters on their own line.
• In multi-line raw string literals, any white space to the left of the closing quotes is removed.

Here’s a simple example—note that string interpolation is also supported:

var author = "Andy Dwyer";  
string longMessage = $"""  
"Leslie, I typed your symptoms  
into this thing here and  
it says you have 'internet  
'connectivity problems.'"  
  
— {author}  
""";  
  
Console.WriteLine(longMessage);  

The value is immediate when working with JSON or XML-like structures, like this:

string html = """
           <body style="normal">
              <div class="book-content">
               This is information about the "C# 11" book.
           </body>
           <footer>
               This is information about the author of the "C# 11" book.
           </footer>
       </element>
       """;

Output Caching Middleware in ASP.NET Core 7

In his session, Output Caching in ASP.NET Core 7, Sebastian Ros talked about new middleware for caching endpoints.

If you aren’t familiar, ASP.NET Core already has response caching middleware that enables developers to enable caching sever responses based on HTTP cache headers. This has limited value for UI apps like Blazor and Razor Pages, as browsers often set request headers to prevent caching. Also, the response caching middleware has limited customization options.

The new output caching middleware will allow ASP.NET Core developers to:

• Store the results in a web application instead of executing it repeatedly, providing performance benefits
• Configure caching without having to think about HTTP headers
• Storage options (like saving to disk or Azure Storage)
• Use tags to invalidate cache entries
• Have resource locking enabled by default

You’ll be able to use this through a variety of ASP.NET Core web apps, but let’s see how it works using a Minimal API. To start, let’s cache the root endpoint. To tweak Sebastian’s example ever so slightly, let’s say we’ve got a lawn care shop called Mandy’s Mowers, where we fetch details of the lawn mowers for sale.

using Microsoft.AspNetCore.OutputCaching;
using Microsoft.AspNetCore.OutputCaching.Policies;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOutputCaching();

var app = builder.Build();

app.UseOutputCaching();
app.MapGet("/", MowerInventory.GetMowers).OutputCache();
await app.RunAsync();

If I want to disable caching for an endpoint, I would do this:

app.MapGet("/nocache", MowerInventory.GetMowers).OutputCache(cache => cache.NoStore());

If I want to enable caching for all endpoints, I can add a policy to the configuration.

builder.Services.AddOutputCaching(options =>
{
  options.Policies.Add(new OutputCachingPolicy());
});

You can also assign policies to specific endpoints. Let’s say I want to cache product detail results pages for just 15 seconds:

builder.Services.AddOutputCaching(options =>
{
  options.Policies.Add(new OutputCachingPolicy());
  options.Profiles["QuickCache"] = new OutputCachePolicyBuilder().Expires(TimeSpan.FromSeconds(15)).Build();
});

// other code omitted for brevity

app.MapGet("/results", MowerInventory.GetMowers).OutputCache(cache => cache.Profile("QuickCache"));

If you want to cache by query string value, you can do that too. Consider this endpoint where a user filters by type and color.

https://mandysmowers.com/results?type=push&color=red

If I wanted to only specify a caching policy by color, I can use the VaryByQuery API:

app.MapGet("/results", MowerInventory.GetMowers).OutputCache(p => p.VaryByQuery("color"));

Of course, you can also work with nested endpoints, too. A common scenario would be pages for getting all mowers, and also displaying a specific one.

We’d first set up a policy:

builder.Services.AddOutputCaching(options =>
{
    options.Policies.Add(new OutputCachingPolicy());
    options.Policies.Add(new OutputCachePolicyBuilder().Path("/mowers").Tag("mowers").Build());
});

Then, apply a tag to the endpoints:

app.MapGet("/mowers", MowerInventory.GetMowers).OutputCache(cache => cache.Tag("mowers"));
app.MapGet("/mowers/{id}", MowerInventory.GetMowers).OutputCache(cache => cache.Tag("mowers"));

Then, you could perform actions on a tag in a single action, like with performing cache eviction. As shown in the talk, you could build a /purge endpoint to do this:

app.MapPost("/purge/{tag}", async (IOutputCacheStore cache, string tag))
{
    await cache.EvictByTagAsync(tag);
};

There’s a lot more to come to this exciting feature, and you can follow it on GitHub.

Minimal API Updates

In Stephen Halter and Safia Abdalla’s talk, Minimal APIs: Past Present and Future, they discussed how Minimal APIs have evolved and what’s in store for .NET 7.

If you aren’t familiar with Minimal APIs, you use them to create HTTP APIs with minimal dependencies and overhead without the bloat that often comes with ASP.NET Core MVC. (Of course, MVC is going nowhere and it’s up to you to determine what best fits your use case.)

I initially wrote about Minimal APIs in their early days and also wrote about their capabilities with .NET 6. As discussed in the talk, .NET 6 was when Minimal APIs truly arrived, taking advantage of top-level statements, lambdas and method groups, attributes on lambdas, new Map methods, and more. Looking forward to .NET 7, here are some of my favorites.

Endpoint Filters

With .NET 7, Minimal APIs will support endpoint filters, which allow you to inspect and modify input parameters before executing a route handler. This will allow developers to intercept a request, much like in an MVC controller, and perform logic based on the parameters.

This involves a new IRouteHandlerFilter interface that takes a RouteHandlerFilterContext which developers can implement for custom filters. The RouteHandlerFilterContext contains HttpContext and Parameters properties—the Parameters is an IList so developers can perform updates on the fly.

Route Groups

.NET 7 also ships route groups that allow you to define a single route prefix for a group of endpoints, which allow a variety of IEndpointConventionBuilder extension methods (like RequireCors and RequireAuthorization). You can say goodbye to manually adding authorization to single endpoints. It also allows nesting.

Typed Results

With .NET 7 Preview 4, typed results should make working with and testing route handlers simpler and easier. To borrow from the talk, here’s a quick example.

In .NET 6, here’s how you could return a specific response based on if a record with a specific type is found:

app.MapGet("/todo/{id}", async (int id, ToDoDb db) =>
    await db.Todos.FindAsync(id) is Todo todo
        ? Results.Ok(todo)
        : Results.NotFound());

And here’s how it looks with typed results in .NET 7:

app.MapGet("/todo/{id}", async Task<Results<Ok<Todo>, NotFound>> (int id, ToDoDb db) =>
    await db.Todos.FindAsync(id) is Todo todo;

This makes testing a lot easier, as this example shows:

[Fact]
public async Task GetAllTodos_ReturnsOk()
{
    var db = CreateDbContext();
    var result = await TodosApi.GetAllTodos(db);
    Assert.IsType<Ok<object>>(result);
}

Wrap-up

I’ve only scratched the surface on all the great .NET web content from Build 2022. The .NET team put together a YouTube playlist of .NET Build content, and you can also check out all 389 on-demand sessions. Here are a few other talks I loved but didn’t have space to address:

• Next Steps for Distributed Programming with .NET and Orleans
• .NET MAUI - Updates and Roadmap
• Visual Studio 2022 and Beyond
• Future Possibilities for .NET Core and WASI (WebAssembly on the Server)

Stay tuned, as we’ll cover many of these topics as we get closer to the .NET 7 release in November. Happy coding!

Have you heard? .NET 6 has officially arrived. There's a lot of good stuff: C# 10, performance improvements, Hot Reload, Minimal APIs, and much more. As is the case for most releases, a few big features tend to get most of the hype.

What about the features and improvements that don't knock both your socks off but also help to make your daily development experience more productive? A lot of these "quality of life" features in .NET 6 can help by removing boilerplate and pain and can help you get to the point: shipping quality software.

As I get into the holiday spirit, consider this a stocking of sorts: just some random, little things that I hope you'll find enjoyable. (And despite the catchy title, there are always tradeoffs: do what works for you.)

Don't chunk large collections manually, use the new LINQ API instead

When working with large collections of data, you likely need to work with smaller "chunks" of it—a big use case would be if you're getting a lot of data back from a third-party API. If there's no pagination set up and you have a bunch of data in memory, you'll probably want a way to "page" or split up the data.

What's a .NET developer to do? Do things the hard way. You'd probably do some logic to set a page size, check what page you're on and if there are any elements left, then update your code when you add pages to a collection. It'd be a series of Take and Skip LINQ calls, or maybe even an extension method, like this one that's popular on Stack Overflow:

static class LinqExtensions
{
    public static IEnumerable<IEnumerable<T>> Split<T>(this IEnumerable<T> list, int parts)
    {
        int i = 0;
        var splits = from item in list
                     group item by i++ % parts into part
                     select part.AsEnumerable();
        return splits;
    }
}

Don't do that, do this: use the new LINQ Chunk API. When we call Chunk on 200 elements, we'll get 20 lists of 10 elements each.

int pageSize = 10;
IEnumerable<Employee[]> employeeChunk = employees.Chunk(pageSize);

If you need just a date, don't use DateTime, use DateOnly

If you want to work with dates and times in .NET, you typically start with DateTime, TimeSpan, or DateTimeOffset. What if you only need to work with dates and only need a year, month, or day? In .NET 6, you can use a new DateOnly struct. (You can also use TimeOnly. I also promise this isn't the start of a dating app.)

We've all done something like this:

var someDateTime = new DateTime(2014, 8, 24);
var justTheDate = someDateTime.ToShortDateString();

Console.WriteLine(someDateTime); // 8/24/2014 12:00:00 AM
Console.WriteLine(justTheDate); // "8/24/2014"

Don't do that, do this: use the DateOnly struct.

var someDateTime = new DateOnly(2014, 8, 24);
Console.WriteLine(someDateTime); // 8/24/2014

There's a lot more you can do with these, obviously, in terms of manipulation, calculation days between dates, and even combining with DateTime. Apart from being easier to work with, it also offers better type safety for just dates, a Kind property, and simpler serialization.

Don't wire up a lot of custom code for logging HTTP requests, use the new logging middleware

Before .NET 6, logging HTTP requests wasn't hard but a little cumbersome. Here's one way: you'd probably have logic to read the request body, use your expert knowledge of ASP.NET Core middleware to pass the stream to whatever is next on the pipeline, and remember to register your middleware—all for a very common activity for any reasonably complex web application.

Don't do that, do this: use the new .NET 6 HTTP Logging middleware to make your life easier.

Add this to your project's middleware:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseHttpLogging();

    // other stuff here, removed for brevity
}

Then, customize the logger as you see fit.

public void ConfigureServices(IServiceCollection services)
{
    services.AddHttpLogging(logging =>
    {
        logging.LoggingFields = HttpLoggingFields.All;
        logging.RequestHeaders.Add("X-Request-Header");
        logging.ResponseHeaders.Add("X-Response-Header");
        logging.RequestBodyLogLimit = 4096;
        logging.ResponseBodyLogLimit = 4096;
    });
}

You'll want to be watchful of what you log and how often you log it, but it's a great improvement.

Don't use hacks to handle fatal Blazor Server exceptions, use the ErrorBoundary component

What happens when an unhandled exception in Blazor Server occurs? It's treated as fatal because "the circuit is left in an undefined state which could lead to stability or security problems in Blazor Server." As a result, you might need to throw try/catch blocks all over the place as a preventive measure or encapsulate logic in JavaScript since no C# code runs after the unhandled exception.

Don't do that, do this: use the new ErrorBoundary component. It isn't a global exception handler but will help deal with unpredictable behavior, especially with components you don't and can't control.

You can see my article for the full treatment, but here's the gist: I can add an ErrorBoundary around the @Body of my default layout.

<div class="main">
    <div class="content px-4">
        <ErrorBoundary>
            @Body
        </ErrorBoundary>
    </div>
</div>

Of course, you probably want to go further than a catch-all boundary. Here's me iterating through a list:

<tbody>
    @foreach (var employee in Employees)
    {
        <ErrorBoundary @key="@board">
            <ChildContent>
                <tr>
                    <td>@employee.Id</td>
                    <td>@employee.FirstName</td>
                    <td>@employee.LastName</td>
                 </tr>
            </ChildContent>
            <ErrorContent>
                Sorry, I can't show @employee.Id because of an internal error.
            </ErrorContent>
        </ErrorBoundary>
    }
</tbody>

Don't use Server.Kestrel verbose logging for just a few things, use the new subcategories

If I want to enable verbose logging for Kestrel, I'd previously need to use Microsoft.AspNetCore.Server.Kestrel. That still exists, but there are also new subcategories that should make things less expensive. (Computationally; you're still on the hook for holiday gifts, sorry.)

In addition to Server.Kestrel, we now have Kestrel.BadRequests, Kestrel.Connections, Kestrel.Http2, and Kestrel.Http3.

Let's say you only want to log bad requests. You'd normally do this:

{
  "Logging": {
    "LogLevel": {
      "Microsoft.AspNetCore.Server.Kestrel": "Debug"
    }
  }
}

Don't do that. Do this:

{
  "Logging": {
    "LogLevel": {
      "Microsoft.AspNetCore.Server.Kestrel.BadRequests": "Debug"
    }
  }
}

Is it the sexiest thing you'll read today? Unless you love logging more than I thought you did, probably not. But it'll definitely make working with Kestrel verbose logging much easier.

Don't get lost in brackets, use C# 10 file-scoped namespaces instead

C# 10 introduces the concept of file-scoped namespaces.

Here's a typical use of namespaces in C#:

namespace SuperheroApp.Models
{
   public class Superhero
   {
      public string? FirstName { get; set; }
      public string? LastName { get; set; }
   }
}

Instead of downloading a bracket colorizer extension, do this instead:

namespace SuperheroApp.Models;

public class Superhero
{
   public string? FirstName { get; set; }
   public string? LastName { get; set; }
}

Also, for the record (ha!), you can make this even simpler if you want to take advantage of immutability and value-like behavior:

namespace SuperheroApp.Models;

public record Superhero(string? FirstName, string? LastName);

You should be aware of what you're getting with positional parameters, but we can all agree this isn't your grandma's C# (and I'm here for all of it, my apologies to grandma).

Speaking of brackets ...

Since we're on the topic of brackets, C# 10 also introduces extended property patterns.

You could use property patterns in a switch expression like this:

public static int CalculateSuitSurcharge(Superhero hero) =>

        hero switch
        {
            { Suit: { Color: "Blue" } } => 100,
            { Suit: { Color: "Yellow" } } => 200,
            { Suit: { Color: "Red" } } => 300
            _ => 0
        };

Don't do that. Do this:

public static int CalculateSuitSurcharge(Superhero hero) =>

        hero switch
        {
            { Suit.Color: "Blue" } => 100,
            { Suit.Color: "Yellow" } => 200,
            { Suit.Color: "Red" } => 300
            _ => 0
        };

Wrapping up

I hope you enjoyed this post, and you learned a thing or two about how .NET 6 can make your developer life just a little bit easier. Have you tried any of these? Do you have others to share? Let me know in the comments or on Twitter.

For the second straight November, .NET developers have received an early holiday gift: a new release of the .NET platform. Last month, Microsoft made .NET 6 generally available—and hosted a virtual conference to celebrate its new features.

What were the goals of .NET 6? If you look at themesof.net, you can quickly see the themes of the .NET 6 release, which include some of the following:

• Appeal to net-new devs, students, and new technologists
• Improve startup and throughput using runtime exception information
• The client app development experience
• Recognized as a compelling framework for cloud-native apps
• Improve inner-loop performance for .NET developers

We could spend the next ten blog posts writing about all the new .NET 6 improvements and features. I'd love to do that, but I haven't even started shopping for the holidays. Instead, I'd like to show off some of my favorite things that I'll be using on my .NET 6 projects. Most of these changes revolve around web development in ASP.NET Core 6 since this site focuses on those topics.

Hot Reload

Way back in April, I wrote here about the Hot Reload capability in .NET 6. We've come a long way since then, but I felt the same as I do now: this is the biggest boost to a .NET web developer's productivity over the last few years. If you aren't familiar with Hot Reload, let's quickly recap.

The idea of "hot reload" has been around for quite a few years: you save a file, and the change appears almost instantaneously. Once you work with hot reloading, it's tough to go back. As the .NET team tries to attract outsiders and new developers, not having this feature can be a non-starter to outsiders: it's table stakes for many developers. The concept is quite popular in the front-end space and .NET developers have been asking for this for a while. (Admittedly, introducing hot reload to a statically typed language is much more complex than doing it for a traditionally interpreted language like JavaScript.)

With .NET 6, you can use Hot Reload to make changes to your app without needing to restart or rebuild it. Hot Reload doesn't just work with static content, either—it works with most C# use cases and also preserves the state of your application as well—but you'll want to hit up the Microsoft Docs to learn about unsupported app scenarios.

Here's a quick example to show how the application state gets preserved in a Blazor web app. If I'm in the middle of an interaction and I update the currentCount from 0 to 10, will things reset? No! Notice how I can continue increasing the counter, and then my counter starts at 10 when I refresh the page.

You can leverage Hot Reload in whatever way you prefer: powerful IDEs like JetBrains Rider and Visual Studio 2022 have this capability. You can also utilize it from the command line if you prefer (yes, we do). It's important to mention that this works for all ASP.NET Core Web apps.

Minimal APIs

Have you ever wanted to write simple APIs in ASP.NET Core quickly but felt helpless under the bloat of ASP.NET Core MVC, wishing you could have an Express-like model for writing APIs?

The ASP.NET team has rolled out minimal APIs—a new, simple way to build small microservices and HTTP APIs in ASP.NET Core. Minimal APIs hook into ASP.NET Core's hosting and routing capabilities and allow you to build fully functioning APIs with just a few lines of code. Minimal APIs do not replace building APIs with MVC—if you are building complex APIs or prefer MVC, you can keep using it as you always have—but it's an excellent approach to writing no-frills APIs. We wrote about it in June, but things have evolved a lot since then. Let's write a simple API to show it off.

First, the basics: thanks to lambdas, top-level statements, and C# 10 global usings, this is all it takes to write a "Hello, Telerik!" API.

var app = WebApplication.Create(args);
app.MapGet("/", () => "Hello, Telerik!");
app.Run();

Of course, we'll want to get past the basics. How can I really use it? Using WebApplication, you can add middleware just like you previously would in the Configure method in Startup.cs. In .NET 6, your configuration takes place in Program.cs instead of a separate Startup class.

var app = WebApplication.Create(args);
app.UseResponseCaching(); 
app.UseResponseCompression(); 
app.UseStaticFiles();

// ...

app.Run();

If you want to do anything substantial, though, you'll want to add services using a WebApplicationBuilder (again, like you typically would previously in the ConfigureServices method in Startup.cs):

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSingleton<MyCoolService>();
builder.Services.AddSingleton<MyReallyCoolService>();

builder.Services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new() {
        Title = builder.Environment.ApplicationName, Version = "v1" });
});

var app = builder.Build();

// ...

app.Run();

Putting it all together, let's write a simple CRUD API that works with Entity Framework Core and a DbContext. We'll work with some superheroes because apparently, that's what I do. With the help of record types, we can make our data models a little less verbose, too.

using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<SuperheroDb>(o => o.UseInMemoryDatabase("Superheroes"));

builder.Services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new() {
        Title = builder.Environment.ApplicationName, Version = "v1" });
});

var app = builder.Build();

app.MapGet("/superheroes", async (SuperheroDb db) =>
{
    await db.Superheroes.ToListAsync();
});

app.MapGet("/superheroes/{id}", async (SuperheroDb db, int id) =>
{
    await db.Superheroes.FindAsync(id) is Superhero superhero ?
    	Results.Ok(superhero) : Results.NotFound();
});

app.MapPost("/superheroes", async (SuperheroDb db, Superhero hero) =>
{
    db.Superheroes.Add(hero);
    await db.SaveChangesAsync();

    return Results.Created($"/superheroes/{hero.Id}", hero);
});

app.MapPut("/superheroes/{id}",
    async (SuperheroDb db, int id, Superhero heroInput) =>
    {
        var hero = await db.Superheroes.FindAsync(id);
        
        if (hero is null)
           return Results.NotFound();

        db.Update(heroInput);
        await db.SaveChangesAsync();

        return Results.NoContent();
    });


app.MapDelete("/superheroes/{id}",
    async (SuperheroDb db, int id) =>
    {
        var hero = await db.Superheroes.FindAsync(id);
        if (hero is null)
            return Results.NotFound();

        db.Superheroes.Remove(hero);
        await db.SaveChangesAsync();
        return Results.Ok();
    });

app.Run();

record Superhero(int Id, string? Name, int maxSpeed);

class SuperheroDb : DbContext
{
    public SuperheroDb(DbContextOptions<SuperheroDb> options)
        : base(options) { }

    public DbSet<Superhero> Todos => Set<Superhero>();
}

As you can see, you can do a lot with Minimal APIs while keeping them relatively lightweight. If you want to continue using MVC, that's your call—but with APIs in .NET you no longer have to worry about the overhead of MVC if you don't want it. If you want to learn more, David Fowler has put together a comprehensive document on how to leverage Minimal APIs—it's worth checking out.

Looking at the code sample above, it's easy to wonder if this is all a race to see what we can throw in the Program.cs file and how easy it is to get messy. This can happen in any app: I don't know about you, but I've seen my share of controllers that were rife for abuse.

It's essential to see the true value of this model—not how cool and sexy it is to write an entire .NET CRUD API in one file, but the ability to write simple APIs with minimal dependencies and exceptional performance. If things look unwieldy, organize your project as you see fit, just like you always have.

Simplified HTTP logging

How often have you used custom middleware, libraries, or solutions to log simple HTTP requests? I've done it more than I'd like to admit. .NET 6 introduces HTTP Logging middleware for ASP.NET Core apps that log information about HTTP requests and responses for you, like:

• Request information
• Properties
• Headers
• Body data
• Response information

You can also select which logging properties to include, which can help with performance too.

To get started, add this in your project's middleware:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseHttpLogging();

    // other stuff here, removed for brevity
}

To customize the logger, you can use AddHttpLogging:

public void ConfigureServices(IServiceCollection services)
{
    services.AddHttpLogging(logging =>
    {
        logging.LoggingFields = HttpLoggingFields.All;
        logging.RequestHeaders.Add("X-Request-Header");
        logging.ResponseHeaders.Add("X-Response-Header");
        logging.RequestBodyLogLimit = 4096;
        logging.ResponseBodyLogLimit = 4096;
    });
}

If we want to pair this with a Minimal API, here's how it would look:

using Microsoft.AspNetCore.HttpLogging;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHttpLogging(logging =>
{
    logging.LoggingFields = HttpLoggingFields.All;
    logging.RequestHeaders.Add("X-Request-Header");
    logging.RequestHeaders.Add("X-Response-Header");
    logging.RequestBodyLogLimit = 4096;
    logging.ResponseBodyLogLimit = 4096;
});

var app = builder.Build();
app.UseHttpLogging();

app.MapGet("/", () => "I just logged the HTTP request!");

app.Run();

Blazor improvements

.NET 6 ships with many great updates to Blazor, the client-side UI library that's packaged with ASP.NET Core. I want to discuss my favorite updates: error boundaries, dynamic components, and preserving pre-rendered state. Check out Jon Hilton's great post if you want to learn more about .NET 6 Blazor updates.

Error boundaries

Blazor error boundaries provide an easy way to handle exceptions within your component hierarchy. When an unhandled exception occurs in Blazor Server, it's treated as a fatal error because the circuit hangs in an undefined state. As a result, your app is as good as dead, it loses its state, and your users are met with an undesirable An unhandled error has occurred message, with a link to reload the page.

Inspired by error boundaries in React, the ErrorBoundary component attempts to catch recoverable errors that can't permanently corrupt state—and like the React feature, it also renders a fallback UI.

I can add an ErrorBoundary around the @Body of a Blazor app's default layout, like so.

<div class="main">
    <div class="content px-4">
        <ErrorBoundary>
            @Body
        </ErrorBoundary>
    </div>
</div>

If I get an unhandled exception, I'll get the default fallback error message.

Of course, you can always customize the UI yourself.

<ErrorBoundary>
    <ChildContent>
        @Body
    </ChildContent>
    <ErrorContent>
        <p class="custom-error">Woah, what happened?</p>
    </ErrorContent>
</ErrorBoundary>

If you'd like the complete treatment, check out my post from earlier this summer.  It still holds up (even the MAUI Man references).

Dynamic components

What happens if you want to render your components dynamically when you don't know your types ahead of time? It previously was a pain in Blazor through a custom render tree or declaring a series of RenderFragment components. With .NET 6, you can render a component specified by type. When you bring in the component, you set the Type and optionally a dictionary of Parameters.

<DynamicComponent Type="@myType" Parameters="@myParameterDictionary" />

I find dynamic components especially valuable when working with form data—you can render data based on selected values without iterating through a bunch of possible types. If this interests you (or if you like rockets), check out the official documentation.

Preserving pre-rendered state

Despite all the performance and trimming improvements with Blazor WebAssembly, initial load time remains a consideration. To help with this, you can prerender apps from the server to help with its perceived load time. This means that Blazor can immediately render your app's HTML while it is wiring up its dynamic bits. That's great, but it also previously meant that any state was lost.

Help has arrived. To persist state, there's a new persist-component-state tag helper that you can utilize:

<component type="typeof(App)" render-mode="ServerPrerendered" />
<persist-component-state />

In your C# code, you can inject PersistComponentState and register an event to retrieve and ultimately persist the objects. On subsequent loads, your OnInitializedAsync method can retrieve data from the persisted state—if it doesn't exist, it'll get the data from your original method (typically a service of some sort).

To see it in action, check out the Microsoft documentation.

C# 10 updates

Along with .NET 6, we've also got a new version of C#—C# 10. It ships with some great new features, like file-scoped namespaces, global usings, lambda improvements, extended property patterns, null argument checks, and much more. Check out Joseph Guadagno's blog post for more details, as well as Microsoft's blog post.

In this post, I'd like to show an authorization "gotcha" to keep in mind and a few things I learned that might help you.

Authorize AzCopy to access your Azure Storage account and Amazon S3

After you install AzCopy—the installation is a .zip or .tar file depending on your environment—you'll need to let AzCopy know that you are authorized to access the Amazon S3 and Azure Storage resources.

From the Azure side, you can elect to use Azure Active Directory (AD) or a SAS token.  For me, I ran azcopy login to log in to Azure with my credentials. If you want to run inside a script or have more advanced use cases, it's a good idea to authorize a managed identity.

With ownership access to the storage account, I thought that was all I needed. Not so fast!

You will also need one of these permissions in Azure AD:

• Storage Blob Data Reader (downloads only)
• Storage Blob Data Contributor
• Storage Blob Data Owner

Note: Even if you are a Storage Account Owner, you still need one of those permissions.

You'll need to grab an Access Key ID and AWS Secret Access Key from Amazon Web Services. If you're not sure how to retrieve those, check out the AWS docs.

From there, it's as easy as setting a few environment variables (I'm using Windows):

• set AWS_ACCESS_KEY_ID=<my_key>
• set AWS_SECRET_ACCESS_KEY=<my_secret_key>

Copy an AWS bucket directory to Azure Storage

I needed to copy all the files from a public AWS directory with the pattern /my-bucket/dir/dir/dir/dir/ to a public Azure Storage container. To do that, I called azcopy like so:

azcopy "https://s3.amazonaws.com/my-bucket/dir/dir/dir/dir/*" "https://mystorageaccount.blob.core.windows.net/mycontainer" --recursive=true

This command allowed me to take anything under the directory while also keeping the file structure from the S3 bucket. I knew that it was all PDF files, but I could have also used the --include-pattern flag like this:

azcopy "https://s3.amazonaws.com/my-bucket/dir/dir/dir/dir/*" "https://mystorageaccount.blob.core.windows.net/mycontainer" --include-pattern "*.pdf" --recursive=true

There's a lot of flexibility here—you can specify multiple complete file names, wildcard characters (I could have set multiple file types here), and even based on file modified dates. I might need to be more selective in the future, so I was happy to see all the options at my disposal.

Resuming jobs

If running AzCopy for a while, you might deal with a stopped job. It could be because of failures or a system reboot. To start where you left off, you can run azcopy jobs list to get a list of your jobs in this format:

Job Id: <some-guid>
Start Time: <when-the-job-started>
Status: Cancelled | Completed | Failed
Command: copy "source" "destination" --any-flags

With the correct job ID in hand, I could run the following command to pick up where I left off:

azcopy jobs resume <job-id>

If you need to get to the bottom of any errors, you can change the default log level (the default is INFO) and filter by jobs with a Failed state. AzCopy creates log and plan files for every job you run in the %USERPROFILE%\.azcopy directory on Windows.

After you finish, you can clean up all your plan and log files by executing azcopy jobs clean (or azcopy jobs rm <job-id> if you want to remove just one).

Performance optimization tips

Microsoft recommends that individual jobs contain no more than 10 million files. Jobs that transfer more than 50 million files can suffer from degraded performance because of the tracking overhead. I didn't need to worry about performance, but I still learned a few valuable things.

To speed things up, you can increase the number of concurrent requests by setting the AZCOPY_CONCURRENCY_VALUE environment variable. By default, Microsoft sets the value to 16 multiplied by the number of CPUs on your machine—if you have less than 5 CPUs, the value is 16. Because I have 12 CPUs, AzCopy set the AZ_CONCURRENCY_VALUE to 192.

If you'd like to confirm, you can look at the top of your job's log file.

2021/11/19 16:39:20 AzcopyVersion  10.13.0
2021/11/19 16:39:20 OS-Environment  windows
2021/11/19 16:39:20 OS-Architecture  amd64
2021/11/19 16:39:20 Log times are in UTC. Local time is 19 Nov 2021 10:39:20
2021/11/19 16:39:20 Job-Command copy https:/mystorageaccount.blob.core.windows.net/my-container --recursive=true 
2021/11/19 16:39:20 Number of CPUs: 12
2021/11/19 16:39:20 Max file buffer RAM 6.000 GB
2021/11/19 16:39:20 Max concurrent network operations: 192 (Based on number of CPUs. Set AZCOPY_CONCURRENCY_VALUE environment variable to override)
2021/11/19 16:39:20 Check CPU usage when dynamically tuning concurrency: true (Based on hard-coded default. Set AZCOPY_TUNE_TO_CPU environment variable to true or false override)
2021/11/19 16:39:20 Max concurrent transfer initiation routines: 64 (Based on hard-coded default. Set AZCOPY_CONCURRENT_FILES environment variable to override)
2021/11/19 16:39:20 Max enumeration routines: 16 (Based on hard-coded default. Set AZCOPY_CONCURRENT_SCAN environment variable to override)
2021/11/19 16:39:20 Parallelize getting file properties (file.Stat): false (Based on AZCOPY_PARALLEL_STAT_FILES environment variable)

You can tweak these values to see what works for you. Luckily, AzCopy allows you to run benchmark tests that will report a recommended concurrency value.

Wrap up

This was my first time using AzCopy for any serious work, and I had a good experience. It comes with a lot more flexibility than I imagined and even has features for limiting throughput and optimizing memory use.

To get started, click the link below to begin using AzCopy—and let me know what you think of it!

Copy or move data to Azure Storage by using AzCopy v10

AzCopy is a command-line utility that you can use to copy data to, from, or between storage accounts. This article helps you download AzCopy, connect to your storage account, and then transfer files.

Microsoft Docsnormesta

Over the last few years, C# has made a lot of property pattern enhancements. Starting with C# 8, the language has supported extended property patterns, a way to match an object's specific properties.

For our example, let's continue the superhero theme with a Person, a Superhero that inherits from Person, and a Suit. We're going to calculate any special surcharges when making a particular superhero's suit.  

public class Person
{
    public string? FirstName { get; set; }
    public string? LastName { get; set; }
    public string? Address { get; set; }
    public string? City { get; set; }
}

public class Superhero : Person
{
    public int MaxSpeed { get; set; }
    public Suit? Suit { get; set; }
}

public class Suit
{
    public string? Color { get; set; }
    public bool HasCape { get; set; }
    public string WordsToPrint { get; set; }
}

Now let's create a quick object for Iron Man:

var tonyStark = new Superhero()
{
    FirstName = "Tony",
    LastName = "Stark",
    Address = "10880 Malibu Point",
    City = "Malibu",
    Suit = new Suit
    {
       Color = "Red",
       HasCape = false
    }
};

In our switch expression, let's say we want to determine special pricing based on a particular suit's color.

Here's how we'd do it in C# 9:

public static int CalculateSuitSurcharge(Superhero hero) =>

        hero switch
        {
            { Suit: { Color: "Blue" } } => 100,
            { Suit: { Color: "Yellow" } } => 200,
            { Suit: { Color: "Red" } } => 300
            _ => 0
        };

With C# 10, we can use dot notation to make it a bit cleaner:

public static int CalculateSuitSurcharge(Superhero hero) =>

        hero switch
        {
            { Suit.Color: "Blue" } => 100,
            { Suit.Color: "Yellow" } => 200,
            { Suit.Color: "Red" } => 300
            _ => 0
        };

Much like before, you can also use multiple expressions at once. Let's say we wanted to charge a surcharge for a notoriously difficult customer. Look at how we can combine multiple properties in a single line.

public static int CalculateSuitSurcharge(Superhero hero) =>

        hero switch
        {
            { Suit.Color: "Blue" } => 100,
            { Suit.Color: "Yellow" } => 200,
            { Suit.Color: "Red", Address: "10880 Malibu Point" }  => 500,
            { Suit.Color: "Red" } => 300
            _ => 0
        };

That's all there is to it. Will this feature change your life? No. Even so, it's a nice update that allows for cleaner and simpler code.

There's a lot more you can do with property patterns as well, so I'd recommend hitting up the Microsoft Docs to learn more.

Patterns - C# reference

Learn about the patterns supported by C# pattern matching expressions and statements.

Microsoft DocsBillWagner

If you're interested in the design proposal, you can also find it below.

Extended property patterns - C# 10.0 draft specifications

This feature specification describes extended property patterns. These enable more convenient syntax to pattern match on properties nested in objects contained in an object.

Microsoft Docsdotnet-bot

Let me know your thoughts below. Happy coding!

In August, I introduced you to Fiddler Jam. What is Jam? In short, it’s a solution to help support and development teams troubleshoot remote issues with web applications in a quick, easy and secure fashion. Think of Jam as a band playing perfectly in sync: replace the instruments with end users, support staff and software developers playing in tune—and better yet, you’ll never have to take requests for “Free Bird.”

If this is your first time learning about Jam, here's a quick rundown. Users of your site can use a Chrome extension to share the full context of an issue, allowing your support team to analyze the data immediately. If needed, developers can reproduce and debug the issue using the Fiddler Everywhere debugging proxy. (If you'd like to learn more about Fiddler Jam basics, check out Rob Lauer's article.)

Jam already has a great set of features, but the development team—let's call them Jammers—has pushed even more capabilities and improvements since we last talked. We can put it through its paces by taking a look at my Blast Off with Blazor site, which I've written about. Let's see what the Jammers have been up to.

Video recordings

When we last talked, we were able to see screenshots of a lot of user actions so we could see what users were doing when issues occurred. When you start to look at a sequence of actions, though, it might be hard to work through all the steps one by one. My favorite update is definitely a new video recording feature.

After a user sends your support team a link to their Jam session, you’ll notice that the first item in the log (“Capturing Started”) is a full video recording of their experience. This only records the tab in which the user allowed their session to be captured. At this phase, you can choose to watch the whole video.

As you watch it, notice how the recording highlights the corresponding log entries as they are happening. You can pause the video where needed and go right where you need to be with full context. You can also click on an event in the log and be sent to the place in the video where it occurred. From there, you can play the recording or go back and forward as needed. Instead of dealing with word-of-mouth context, you’ve got everything you need.

In my case, I have a 14-second capture full of lots of media, searching and scrolling. Watch the play icon at the left and how it jumps through the log events as time passes. Very cool.

While this is a powerful feature, Corporate Dave is here to inform you that Jam enables video recordings and screenshots by default. Be careful when dealing with sensitive data like passwords, credit card numbers, or anything else you want to keep private. Read Fiddler Jam Security for details.

Better tracking for user events

When we last Jam'ed, I briefly discussed how Fiddler Jam could track a few common events, like button clicks. The Jammers have cranked this up a notch and now allow you to track a ton of other events like clicking on div elements, keyboard events, and scroll events.

I don't know about you, but when I debug front-end issues, it isn't as easy as finding that a file wasn't found or there's a big error in the browser console. It's subtle things that make me clamor for the simplicity of Geocities, like event bubbling and misapplied styles.

The Jammers now give us the ability to click the Inspectors tab to understand metadata about the event, like tag type and CSS class. In addition to video recording, you'll see I also have the event highlighted (in this case, typing into a search box) in a convenient screenshot.

Capture storage information

A new option, Capture storage info, allows you to capture local storage and session storage data. If you aren't familiar, local and session storage are HTML5 storage objects that allow you to store data on the client using convenient key-value pairs. Local storage exists until deleted and has no expiration date, while session storage deletes the data when the user closes a browser.

While Corporate Dave will tell you to not store sensitive data here—as local/session storage isn't super secure and, also, the data is easily accessible and hackable from standard browser tooling—it can sometimes be a lightweight solution for simple data lookup. It can work well with simple user preferences or activities: if we want to remember that a user prefers Dark Mode or has already seen our introductory modal that tours our website, we can store it in local storage for easy retrieval.

The Jammers have introduced the ability for you to view storage details from an aptly named Storage Details tab. If I go to a random website—look, the Telerik Blogs website, what a coincidence!—I can determine when a local storage value was set, and what it is.

How do the Advanced Options work now?

With all these great updates, let's take a look at the new Advanced Options that users can set before capturing a session with Fiddler Jam. Most of these are enabled by default, so you won't have to ask users to explicitly turn them on, but let's review. (Don't worry, there isn't a quiz ... yet.)

Unless stated otherwise, all these options are enabled by default.

• Capture video - As we discussed, this option captures video recording from the active, inspected Chrome tab. Corporate Dave says: "If the screen shows sensitive data, consider disabling it."
• Capture screenshots – This option adds a screenshot from the active Chrome tab. Corporate Dave says: "If the screen shows sensitive data, consider disabling it."
• Capture console – This option records any developer console outputs. Again, consider disabling this if your logs have sensitive information.
• Capture storage info - This option captures local or session storage from the Chrome tab.
• Mask cookies – This option masks cookie values so that they aren’t visible in the logs. The cookie names will still be visible.
• Mask all post data – This option masks data sent along in a POST request, like form information. This option is not enabled by default.
• Disable cache – This option asks the browser to skip network requests cache and download fresh content from the server.  

Updated sharing options

In addition to these new Advanced Options, end users can also view capture details and customize who needs to access the session's details.

First, users can access session details by clicking Capture Successful! I imagine the exclamation point to show the excitement that a user's issue will be diagnosed so quickly! Yes!

Users can click this area to see a quick event log. It's a nice sanity check so users can confirm they are sending you the right logs. If they have 92 tabs open—I would never, but some might—this will help provide a sanity check to make sure they are passing the correct session to you, and not cute cat videos. Again, I would never.

After optionally confirming users are sending the right tab, users can choose to share the details as a link or with specific people. When sharing as a link, I (and Corporate Dave) would suggest using the Password Protection feature.

When you share with specific people, enter the recipient email addresses(es) to send it over electronic mail. When you do this, only the people with corresponding email addresses will have access to it.

More coming!

There's more coming to Fiddler Jam soon—consider bookmarking the Fiddler Jam roadmap for details.

Get started with Fiddler Jam today by going to the Fiddler Jam site and signing up for a free 14-day trial.

Pretty good work from the Jammers, yes? Good work, team. Take the rest of the day off. You've deserved it.

I wouldn't call the newsletter a smashing success by any means, but was thrilled that something I started while bored during a pandemic grew to a few thousand readers every week on various mediums (whether over e-mail, dev.to, or daveabrock.com). I'm grateful to all of you for reading and being so supportive—and if it helped you, I'm even happier. It's been a lot of fun and I've even "met" quite a few friends along the way, even if we've never physically met.

I initially set out to produce something more substantive and not a weekly thing where I send out links every week, as I felt there wasn't a lot of that out there. I wanted to write about trends and topics, and interview folks, and provide a little more context. I quickly realized why there wasn't a lot of that out there: it's so much work to do that on a weekly basis, week in, week out.

With a busy personal life, I'm passionate about community work but with limited time. I did a lot of work to automate things as I could, but The .NET Stacks doesn't leave time for any other community work or projects that I'm passionate about. To me, I could either slim down the newsletter and its quality and make it easier to manage, or focus work in other areas. I've chosen the latter.

It's hard to believe I've produced 70 weekly issues over 18 months, and have used the newsletter to ramble about .NET to the tune of about 104,000 words. Thanks to you all: thanks for reading every week, and thanks for those of you who have emailed me nice words or to ask if I've lost my marbles—both valid, by the way—and thanks for listening. I hope you'll continue to keep up with me at daveabrock.com. Talk to you soon and keep in touch.

• .NET Open Source: Who does Microsoft want to be?
• Last week in the .NET world

.NET Open Source: Who does Microsoft want to be?

To put it lightly, last week was a very eventful week for the .NET community. I'd like to talk about what happened, what we learned, and what it means for .NET open source.

Before diving in, I want to say that I am voicing my opinions only and my intent is not to "create more drama" or keep harping on about past events. While Microsoft resolved the current issue a few days ago, I often find that I can view events with better clarity after spending a few days stepping back and thinking about it. You might agree with what I have to say, think I'm blowing it out of proportion, or somewhere in between. I expect that.

What happened? If you've been subscribed here for the last few months, you know that one of the core objectives of .NET 6 is to improve the "inner development loop" for the .NET platform. The core feature is the "Hot Reload" functionality, which allows developers to see changes applied instantly while running their application. Already viewed as table stakes for modern web application development—front-end developers have enjoyed this capability for many years—it's finally making its way to the .NET platform. As the .NET team is trying to embrace new developers or developers from other platforms, it's a key selling point. If you try to get React or Angular developers to consider something like Blazor, and they learn it isn't available out of the box, you'll likely get a "Seriously?" Once you have it, you can't live without it.

Anyway, Hot Reload was announced and then rolled out in .NET 6 Preview 3, and I wrote about it in detail all the way back in April. At the time, it was rolled out in the .NET CLI via dotnet watch as a lot of new features are. Eventually, Microsoft said, it would make its way to Visual Studio or whatever tool you enjoy—but since it resides in the core SDK, you could use it across a wide variety of environments and platforms. It worked well and as a whole, the community was thrilled. Right around the time .NET 6 RC 2 was released last week—the last "preview" release that ships with a go-live production license—Microsoft decided to scrap it from dotnet watch and only make it available for Visual Studio 2022 "so we can focus on providing the best experiences to the most users" so long as you enjoy Visual Studio on Windows. As if it wasn't abundantly clear, .NET engineers leaked to The Verge that this was a business decision made at the CVP level.

After a ton of almost universal backlash, the capability was restored to dotnet watch, in a blog post whose only strength was providing political cover and delivered on none of what we all wanted: being honest, authentic, or transparent with the community.

I don't think anyone is confusing a trillion-dollar corporation for being a charitable organization. And it is true that a majority of .NET developers are on Visual Studio. If Microsoft decided to make this a Visual Studio feature from the beginning, the pushback would be minimal.

The deserved furor comes from Microsoft ripping out a core feature right before completing a release and done with a PR that was closed to community feedback. This all feels like we got transported to Ballmer-esque Microsoft, and not the "new Microsoft" that appears to be less concerned with sticking you to specific tooling but doing all it can to meet you where you are, so long as you deploy your workloads to Azure.

With the popularity of Visual Studio Code and the emergence of wonderful competitive tools like JetBrains Rider, Microsoft is at odds with being open in the name of that fat Azure cash or being protective of pricey enterprise licensing with Visual Studio. This week highlighted their conflict of interest and desire to have their cake and eat it, too.

We've been slowly reaching a breaking point. Over the last few years, Microsoft restricted debugger licensing, the abandonment of MonoDevelop, and now we have the hot reload controversy. Include the .NET Foundation issues, and Microsoft's "open-source friendly" reputation has taken its hits. The common logic is that while Visual Studio is a moneymaker, for sure, it's a rounding error compared to Azure, so it's good business sense for Microsoft to shed its protectionism in favor of inclusiveness and community goodwill.

Of course, none of this criticism should take away from the amazing work the .NET team has done for both their platform and open source. As a matter of fact, that team is likely the most upset here as a decision out of control has hurt their reputation with the community. But where does .NET fit? For me, it begs the question about how Microsoft views .NET: is it an open, innovative platform that drives Azure investment, or a piggy bank that Microsoft executives can shake until every last penny comes out?

To Microsoft's credit, they should be commended for writing their wrongs so quickly. They listened and reacted, and pushed out an apology in just a few days—an amazing feat at a trillion-dollar company with many layers of top-down management. All in all, I think last week was a wonderful testament to the true value of community, where a group of devoted people can help drive change (or undo unfortunate decisions).

However, the apology post is littered with inconsistencies and seems to be protecting senior management's decisions and not their reputation with the community.

The post explains that: "In our effort to scope, we inadvertently ended up deleting the source code instead of just not invoking that code path." In my opinion, this wasn't an engineer running the wrong command, but trying to make a last-minute change at the demands of their management and closing the PR for comments. While reading the post, I couldn't help but feel how it contradicted this new open Microsoft—build what you want, on any platform you want, so long as you use Azure—and reeked of the political cover and protectionism that defined its past.

Where do we go from here? Is this a team hitting some bumps with a recent reorg, or a sign of things to come? Have the higher-ups at Microsoft learned their lessons, or is this the beginning of protecting the most coveted SDK features to their exclusive tooling? And most importantly, how will Microsoft balance conflicts of interest with all their tooling choices? As Visual Studio Code is an amazing editor, as Dustin Gorski and others have wondered aloud, isn't it strange that Microsoft's own .NET platform is one of the worst supported platforms on Code?

If Microsoft wants to be honest with its community, it needs to answer: What do you want .NET to be? To keep it an open, open-source friendly platform, or to make it a piggy bank? It appears to be that Microsoft wants it both ways and risks harming its reputation with the community while promising openness.

We know Microsoft will never have a perfect relationship with its developer community. At the end of the day, their responsibilities are to their shareholders. With that said, I have all the faith in the world in the .NET team. I admire them and all the work they have done on the .NET platform. I hope the team aligns with their management and can eventually be transparent with the community about what they truly want .NET to be—no BS, no corporate-speak.

🌎 Last week in the .NET world

📢 Announcements

• Emily Stoll writes about Visual Studio 2022 UI updates.
• Dmitry Lyalin provides an update on .NET Hot Reload.
• Microsoft introduces vscode.dev.
• Paul Thurrott writes about Microsoft deprecating UWP.
• Kathleen Dollard writes about what's new in F# 6.
• Microsoft releases Windows Terminal Preview 1.12.
• Rachel Appel writes about various updates in Rider 2021.3.

📅 Community and events

• Help decide what questions to answer at the .NET Foundation's next meeting.
• The Uno Blog writes about recent UWP & .NET 5, .NET 6 news and Uno Platform plans.
• Matthew MacDonald writes about lessons learned from dying frameworks.
• Sergey Tihon announces the 2021 F# advent calendar.

🌎 Web development

• Richard MacManus writes about the growth of PWAs.
• The Microsoft Edge Blog writes about the improved authoring and debugging experiences in Microsoft Edge DevTools and Visual Studio Code.
• Davide Bellone writes about pinging endpoints.
• Imar Spaanjars writes about improving your ASP.NET Core site's file handling capabilities.
• David Ramel writes about native dependencies with Blazor WebAssembly.
• Chris Coyier writes about the supports() CSS selector.

🥅 The .NET platform

• Matthew Jones uses LINQ OrDefault() overloads in .NET 6.
• Andrew Lock supports integration tests with WebApplicationFactory in .NET 6.

📔 Languages

• Dave Brock writes about using global declarations in C# 10.
• Khalid Abuhakmeh uses C# to bulk insert records into SQLLite.
• Jorge Levy writes about using Azure Functions with .NET 5.
• Thomas Claudius Huber talks about extended property patterns in C# 10.
• Muhammed Saleem uses IAsyncEnumerable with yield in C#.
• David McCarter writes about collection type performance in C#.

🔧 Tools

• Thomas Scott talks about JetBrains Git plugins.
• Andrea Chiarelli explores the Auth0 ASP.NET Core Authentication SDK.

🏗 Design, testing, and best practices

• Zaher Talab provides API testing tips.
• Derek Comartin writes about leaking value objects from your domain.
• Sam Milbrath writes about managing your energy.
• The Overflow Blog writes about code quality.
• The Stackify Blog discusses top .NET developer skills.
• Oren Eini tracks down a sticky bug.
• Joana Carvalho writes about full-stack observability essentials.
• Peter Vogel unit tests Azure Functions.
• Dennis Doomen writes about his 17 laws of TDD.

🎤 Podcasts

• The .NET Podcast talks about clean code in C#.
• Merge Conflict writes about .NET 6 and C# 10.
• Adventures in .NET talks to Dennis Doomen about Fluent Assertions.
• The Overflow talks about code quality.
• The 6-Figure Developer Podcast talks to Mads Kristensen about Visual Studio 2022.

🎥 Videos

• The ASP.NET Monsters talk about improved .NET 6 LINQ methods.
• Cecil Phillip walks through Dapr.

Anyway, here's what we have going on this week:

• Web updates with .NET 6 RC 2
• New .NET 6 LINQ API: Chunk
• Last week in the .NET world

Web updates with .NET 6 RC 2

Right on time, last week Microsoft rolled out the .NET 6 RC 2 release. It's the second of two "go live" RCs that are actually supported in production. Richard Lander's announcement post gets you up to speed on what is new with C# 10, including record structs, global usings, file-scoped namespaces, interpolated strings, and extended property patterns.

Despite being oh-so-close to the official release next month, the ASP.NET Core team was busy shipping updates for this release and I'd like to pay attention to those. We saw updates in two big areas: native dependencies and Minimal APIs—the latter of which I've admittedly beaten to death, but also plays a pivotal future in how you build new APIs in the .NET ecosystem (if you want to get over MVC, of course).

With Blazor WebAssembly, in .NET 6 you can now use native dependencies that are built to run on WebAssembly. Using new .NET WebAssembly build tools, you can statically link native dependencies. You can use any native code with this, like C/C++ code, archives, or even standalone .wasm modules. If you have some C code, for example, the build tools can compile and link it to a dotnet.wasm file. To extend it some more, you can use libraries with native dependencies as well.

As for Minimal APIs, you can now leverage parameter binding improvements. With RC2, you can use TryParse and BindAsync for inherited methods. For example, BindAsync allows you to bind a complex type using inheritance. Check out Daniel Roth's blog post for details. The RC2 release also makes some OpenAPI enhancements and includes some analyzers to help you find issues with middleware issues or route handling.

It's hard to believe the next .NET 6 announcement will be the full release itself. As part of that .NET Conf will celebrate the launch, and Visual Studio 2022 will launch on November 8. In the year 2021. (I know.)

New .NET 6 LINQ API: Chunk

If you haven't heard, .NET 6 will roll out some nice LINQ API improvements. Matt Eland recently wrote a nice piece about them. As a whole, it's nice to see .NET 6 roll out quite a few API improvements that were previously done with some light hacking. We all do some light hacking, of course, but for millions of .NET developers there are a lot of common use cases—and it's nice to see those being addressed.

My favorite recent LINQ API improvement is the Chunk API. If you work with large collections of objects, you can now chunk them in case you want to work through pagination or other "chunking" use cases. For paging, you previously had to set a page size, loop through the collection, add to some paging collection, and update some counts.

Instead, as Matt notes, you could try something like this:

IEnumerable<Movie[]> chunks = movies.Chunk(PAGE_SIZE);

This should really help folks page through big API datasets. When you don't control the data coming back, you had to set this up yourself. Very nice.

🌎 Last week in the .NET world

📢 Announcements

• Richard Lander announces .NET 6 Preview 2, and Daniel Roth discusses ASP.NET Core updates. Also, David Ortinau introduces .NET MAUI Preview 9.
• Visual Studio 2022 for Mac Preview 2 is now available.
• Jeremy Likness writes about SQL Server temporal tables in EF Core 6.
• Auth0 is now available on Azure.

📅 Community and events

• Brendan Burns provides updates on KubeCon.
• Jeremy Miller writes all about deletes in Marten v4.
• Aaron Stannard writes about the Future of the .NET Foundation and .NET OSS. In related news, The .NET Foundation is holding a Tell Me Anything meeting.
• Microsoft has a VS 2022 launch event on November 8.

🌎 Web development

• Vedran Cindric provides some REST guidance.
• Niels Swimberghe works with Blazor’s new HeadContent and PageTitle.
• Matthew MacDonald throws some cold water on Blazor AOT compilation.

🥅 The .NET platform

• Scott Hanselman debugs a .NET SDK issue.
• Matthew Jones writes about the new Chunk() method in .NET 6.
• Code Maze works through a CQRS validation pipeline with MediatR and FluentValidation.
• Andrew Lock supports EF Core migrations with WebApplicationBuilder.
• Muhammad Rehan Saeed writes about his issues with C# 10 implicit usings.

⛅ The cloud

• Lee Briggs compares Azure container solutions.
• Norm Johanson writes about the new AWS .NET Deployment Experience, and François Bouteruche migrates .NET Framework apps to AWS.
• Daniel Krzyczkowski writes about async communication with the Azure Service Bus.
• Pavel Krymets introduces experimental OpenTelemetry support in the Azure SDK for .NET.
• Stephanie Lee writes about using Azure Functions with .NET 5.

🔧 Tools

• Khalid Abuhakmeh works on cursor paging with Entity Framework Core and ASP.NET Core.
• The Pro Code Guide uses Polly with ASP.NET Core.
• James Croft runs Selenium UI Tests with Azure DevOps.
• Cody Merritt Anhorn enables .NET CLI tab completion.
• Thomas Ardal writes about updating NuGet packages from the command line.
• Davide Bellone adds logs with .NET Core and Serilog.
• Grace Taylor writes about using VS Code themes with Visual Studio 2022.
• Matthias Koch writes about the reworked Copy Code Reference feature in ReSharper and Rider 2021.3 EAP.

🏗 Design, testing, and best practices

• Derek Comartin explores data consistency between microservices.
• Camille Fournier writes about how new managers fail individual contributors.
• Dennis Doomen describes 15 flags that tell you that your testability practices need maturing.
• The Overflow explores design patterns.
• Jennifer Riggins writes about the emergence of observability.

🎤 Podcasts and videos

• Adventures in .NET talk about VS 2022.
• The Coding Blocks asks: should you speak at a conference?
• .NET Rocks talks to Mads Torgersen about C# 10.
• AzureFunBytes talks to Burke Holland about remote development.
• The ASP.NET Monsters build GitHub Actions in C#.
• Scott Hanselman makes the ultimate terminal prompt on Windows 11.
• The .NET MAUI Podcast talks all about .NET 6 RC 2.

To see how this works, let's revisit my model from the last post, a Superhero:

namespace SuperheroApp.Models;

public class Superhero
{
   public string? FirstName { get; set; }
   public string? LastName { get; set; }
   public string? StreetAddress { get; set; }
   public string? City { get; set; }
   public int? MaxSpeed { get; set; }
}

Let's say I wanted to do some basic work with this model in a standard C# 10 console application. It would look something like this.

using SuperheroApp.Models;

var heroList = new List<Superhero>()
{
    new Superhero
    {
        FirstName = "Tony",
        LastName = "Stark",
        StreetAddress = "10880 Malibu Point",
        City = "Malibu",
        MaxSpeed = 500
    },
    new Superhero
    {
        FirstName = "Natasha",
        LastName = "Romanova",
        MaxSpeed = 200
     }
};

foreach (var hero in heroList)
    Console.WriteLine($"Look, it's {hero.FirstName} {hero.LastName}!");

Console.WriteLine($"The first superhero in the list is {heroList.First().FirstName}.");

You'll notice that thanks to top-level statements, the file is already looking pretty slim. If I create a new file, like GlobalUsings.cs, I could store any usings that I want to be shared across my project's C# files. While you can declare global usings anywhere, it's probably a good idea to isolate it somewhere. (This is scoped for the project and not the solution, so if you want this across multiple files you'd want to specify global usings in every project.)

global using ConsoleApp6.Models;

When I go back to my Program.cs file, Visual Studio reminds me that Superhero.Models is referenced elsewhere (in my GlobalUsings.cs), so it can be safely removed.

I can also use the global static keyword when I use common static methods, like the Math class or writing to Console.  While static usings aren't new—they've been around since C# 6—I can use it freely with global usings. Let's update my GlobalUsings.cs file to the following:

global using SuperheroApp.Models;
global using static System.Console;

Back in my Program.cs, Visual Studio tells me I don't need to use Console.

Aside from supporting standard namespaces (and system ones) and static namespaces, you can also use aliases. Let's say I wanted to globally use System.DateTime and alias it as DT. Here's how my GlobalUsings.cs file looks now:

global using SuperheroApp.Models;
global using static System.Console;
global using DT = System.DateTime;

Going back to my main Program.cs, here's how everything looks now:

var heroList = new List<Superhero>()
{
    new Superhero
    {
        FirstName = "Tony",
        LastName = "Stark",
        StreetAddress = "10880 Malibu Point",
        City = "Malibu",
        MaxSpeed = 500
    },
    new Superhero
    {
        FirstName = "Natasha",
        LastName = "Romanova",
        MaxSpeed = 200
     }
};

foreach (var hero in heroList)
    WriteLine($"Look, it's {hero.FirstName} {hero.LastName}!");

WriteLine($"The first superhero in the list is {heroList.First().FirstName}.");
WriteLine($"Last ran on {DT.Now}");

Are some common namespaces globally available by default?

When I created a collection and read from it, I'm using calls from a few standard Microsoft namespaces: System.Collections.Generic and System.Linq. You may have noticed something: why didn't I need to explicitly include these namespaces in a global usings file? The answer lies in the obj/Debug/net6.0 folder. After you build your project, you'll notice a GlobalUsings.g.cs file, which contains implicit usings. Enabled by default in .NET 6, you don't need to explicitly include them.

// <auto-generated/>
global using global::System;
global using global::System.Collections.Generic;
global using global::System.IO;
global using global::System.Linq;
global using global::System.Net.Http;
global using global::System.Threading;
global using global::System.Threading.Tasks;

The funky global:: syntax ensures that you don't see collisions if you have your own namespaces. For example, if I had a few drinks one night and decided to write my own (very buggy) I/O library and call it DaveIsCool.System.IO, this ensures I'm using the Microsoft namespace.

These usings are driven by an <ImplicitUsings> flag in my project file.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>

If you remove the <ImplicitUsings> line, for example, you would see build errors:

A word of caution: in .NET 6 implicit usings are enabled by default, so if implicit usings aren't for you, this is where you would disable it. For details, take a look at the following document from the .NET team.

Breaking change: Implicit `global using` directives in C# projects - .NET

Learn about the breaking change in .NET 6 where the .NET SDK implicitly includes some namespaces globally in C# projects.

Microsoft Docsgewarren

Can I incorporate global usings with project configuration?

To me, it does seem a little strange to be using C# source files to configure project details. If you don't want to use a C# file to specify your global using declarations, you can delete your file and use MSBuild syntax instead.

Once you open your project file, you can encapsulate your global usings in an <ItemGroup>, like so:

<ItemGroup>
    <Using Include="SuperheroApp.Models"/>
    <Using Include="System.Console" Static="True" />
    <Using Include="System.DateTime" Alias="DT" />
</ItemGroup>

Do I have to use these?

Much like other .NET 6 improvements, you can use it as much or as little as you want. You can use nothing but global and implicit using statements, mix them with regular namespace declarations, or do things as we've always done before. It's all up to you.

Between C# 9 top-level statements, implicit and global usings, and file-scoped namespaces, the C# team is removing a lot of clutter from your C# files. For example, here's how our Program.cs file would look in C# 8 or older.

using System;
using System.Collections.Generic;
using System.Linq;
using SuperheroApp.Models;

namespace SuperheroApp
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var heroList = new List<Superhero>()
            {
                new Superhero
                {
                    FirstName = "Tony",
                    LastName = "Stark",
                    StreetAddress = "10880 Malibu Point",
                    City = "Malibu",
                    MaxSpeed = 500
                },
                new Superhero
                {
                    FirstName = "Natasha",
                    LastName = "Romanova",
                    MaxSpeed = 200
                 }
            };

            foreach (var hero in heroList)
                Console.WriteLine($"Look, it's {hero.FirstName} {hero.LastName}!");

            Console.WriteLine($"The first superhero in the list is {heroList.First().FirstName}.");
            Console.WriteLine($"Last ran on {DT.Now}");
        }
    }
}

With top-level statements and global and implicit usings, we now have this.

var heroList = new List<Superhero>()
{
    new Superhero
    {
        FirstName = "Tony",
        LastName = "Stark",
        StreetAddress = "10880 Malibu Point",
        City = "Malibu",
        MaxSpeed = 500
    },
    new Superhero
    {
        FirstName = "Natasha",
        LastName = "Romanova",
        MaxSpeed = 200
     }
};

foreach (var hero in heroList)
    WriteLine($"Look, it's {hero.FirstName} {hero.LastName}!");

WriteLine($"The first superhero in the list is {heroList.First().FirstName}.");
WriteLine($"Last ran on {DT.Now}");

What do you think? Let me know in the comments. Stay tuned for my next topic on CRUD endpoints with the new .NET 6 Minimal APIs.

Anyway, here's what we have going on this week (or last week):

• Who moved my cheese: New templates for .NET 6 might surprise you
• Community spotlight: Marten v4 is now live
• Last week in the .NET world

Who moved my cheese: New templates for .NET 6 might surprise you

As the release of .NET 6 is rapidly approaching—with .NET 6 RC2 coming out very soon with the official release next month—you might be taken aback by C# template changes. The .NET team is leveraging top-level statements and implicit using directives for some new .NET 6 templates. For example, top-level statements are helping to drive new capabilities like Minimal APIs. Microsoft has put together a new document, New C# templates generate top-level statements, and you should check it out.

With .NET 6, if you create a new console app using dotnet new console (or from Visual Studio tooling), you might expect to see this:

using System;

namespace MyVerboseApp
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

Think again. You'll see this instead:

// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World!");

Much like with top-level statements, you probably have one of two opinions: it eliminates boilerplate and makes it simpler and more beginner-friendly; or it provides too many abstractions and "I didn't ask for this." I do like top-level statements and agree it eliminates a lot of boilerplate. When it comes to using args, though, I like to see where they are being passed in and not just a magic variable.

As of now, to stay consistent with Microsoft pushing to make C# more concise and accessible, it looks like this will be the default template. You can always use the "old" program style from the terminal using framework and target-framework-override flags. This allows you to use the "old" template but force the project framework to be .NET 6.0. (It would have been simpler to pass in --leave-my-stuff-alone, but I digress.)

dotnet new console --framework net5.0 --target-framework-override net6.0

In terms of the tooling experience, the obvious answer will be to eventually introduce a checkbox in Visual Studio to enable/disable these simplified layouts. Until then, you can downgrade the target framework moniker (TFM) to net5.0.

If you don't like it, you can file an issue in the dotnet/templating repo (or chime in on a similar issue), or even create your own templates.

Community spotlight: Marten v4 is now live

Do you know about Marten? It's a popular .NET library that allows you to use Postgresql as both a document database and a powerful event store. Jeremy Miller wrote this week about the new v4 release. Jeremy got my attention with quoting "the immortal philosopher Ferris Bueller" but also highlighted the massive changes:

• Reducing object allocations and dictionary lookups
• LINQ support improvements
• Better tracking for flexible metadata
• Event sourcing improvements

It looks to be a great release, and congrats to the team and all the great contributors. Check out the GitHub repository for more details about the project.

🌎 Last week in the .NET world

📢 Announcements

• Windows 11 has arrived.
• Mark Weitzel provides an update on the Azure REST API guidelines.
• The Azure SDK team rolls out new Azure Monitor client libraries.
• Bri Achtman writes about some ML.NET updates.
• The GitHub Advisory Database now powers npm audit.

📅 Community and events

• Last week was an eventful week for the .NET Foundation. I'm not going to rehash all the events—you can read a thread on the issues, now former Executive Director Claire Novotny's apology, the comments surrounding it, and the announcement of a change in leadership. Let's hope we see structural changes, and don't unfairly scapegoat another invaluable member of the .NET community.
• Myles Borins announces a new public beta of GitHub Releases.
• DaprCon is a thing and is happening next week.
• For community standups: .NET MAUI talks about Hot Reload, EF talks about SQL Server temporal tables and EF Core 6, and ASP.NET updates us on Orchard Core.
• The Netflix Blog writes about how they safely update client applications.
• Community releases: Marten v4 is now live, Blazored Toast v3.2 is released, and Cake v1.3.0 is out.
• FluentValidation has reached 100 million downloads.

🌎 Web development

• David Walsh writes about the accent-color CSS property.
• Damien Bowden implements a secure API and a Blazor app in the same ASP.NET Core project with Azure AD authentication.
• Litan Sarker develops a web app with Angular 12, ASP.NET Core Web API, and SQL Server.
• Mike Brind writes about the Razor Pages startup experience in .NET 6.
• Scott Hanselman writes about Microsoft's guidance on ASP.NET Core diagnostic scenarios.
• David Ramel writes about Azure Functions support for .NET 6.
• Andrew Lock builds a middleware pipeline with WebApplication.
• Nwose Lotanna Victor writes about things developers do to affect web app load time.

🥅 The .NET platform

• Matthew Jones writes about DateOnly and TimeOnly in .NET 6.
• Khalid Abuhakmeh walks through EF Core ConnectionStrings.
• The Code Maze blog writes about code coverage in .NET.
• David McCarter writes about properly disposing of objects in .NET.
• Scott Hanselman writes about the differences between Hashtable, Dictionary, ConcurrentDictionary, and ImmutableDictionary.

⛅ The cloud

• The Microsoft Cloud Show talks about Azure App Configuration.
• Niels Swimberghe collaborates on Power Apps using personal environments, Power Platform CLI, Git, and Azure DevOps.
• Justin Yoo writes about different ways to integrate Azure Functions auth with OpenAPI.

📔 Languages

• Elijah Manor quickly populates a new array in JavaScript.
• Dave Brock works with file-scoped namespaces in C# 10.
• Assis Zang has 6 tips for writing elegant C# code.
• Joël Quenneville asks: who is empowered by your API design?

🏗 Design, testing, and best practices

• Peter Vogel uses JustMock to unit test legacy applications.
• Steven J. Vaughan-Nichols writes about the refresh of the OWASP Top 10.
• Dennis Martinez writes about challenges with automated end-to-end testing.
• Sam Scott and Graham Neray write about best practices for authentication and authorization for REST APIs.
• Davide Bellone offers a clean code tip.
• Sarah Drasner writes about why flow matters more than passion.
• Derek Comartin writes about his top patterns for event-driven architecture.

🎤 Podcasts and videos

• Adventures in .NET talk about pair programming and also continues the discussion on advocating for yourself.
• Jesse Liberty talks to Mads Torgersen about C# 10.
• The .NET Core Show talks to Carl-Hugo Marcotte about ASP.NET Core 5 design patterns.
• Visual Studio Toolbox discusses Solution Filters in Visual Studio.
• On .NET talks about using DynamicData.

Here's what we have this week:

• Exploring modern C#
• Custom deployment layouts for Blazor WebAssembly apps
• Last week in the .NET world

Exploring modern C#

With the official release of .NET 6 next month, we'll see the release of C# 10. Much like the .NET platform as a whole, the language is beginning to adopt incremental, annual releases going forward. The C# 10 release brings us features like record structs, global using directives, extended property patterns, file-scoped namespaces, and so on. Richard Lander's .NET 6 RC2 announcement will be looking into some of these.

As C# has shifted over the years from a strict OO language to a more general-purpose one, it's experienced some pushback on how heavy it's become. We tend to go in circles in the .NET community: yes, there's a lot—it needs to evolve to be a modern language, but it also can't break people who rely on the older features. Right on time, the newsletter Twitter account posted a link to an article asking: is C# too complex? It spawned an interesting discussion, both about the article itself and of C#.

I like what Kathleen Dollard, a Microsoft PM for .NET Core CLI and Languages, had to say:

Still, I don't think it's realistic to expect a single way to do things, but it can get out of hand. As a simple example, there are at least a half dozen ways to check if a string is empty. It's that there are so many ways to do a single thing: some are modern and some best practices, some not—all the while, we know the language will never take anything away for backward compatibility reasons.

For us experienced developers, we can say the language is evolving and just "use what works best for you." What if you don't, or don't want the mental weight of dealing with it all?

As I was listening to C# language designer Mads Torgersen on Bryan Hogan's No Dogma podcast, I found this following exchange quite interesting. (I know there's a lot in this exchange, but I wanted to post it all to avoid taking anything out of context.)

Q: All of these new features, feel like new ways of doing old things and I would imagine they could get confusing. A criticism about C# that's been around for a while is that there are so many ways to do one thing anyway, and now you've added a whole bunch of new ways to do things I could do already.

A: Yes. That's a real challenge. If you have a programming language and you want to keep it the best option for somebody making the next project, it has to be modern. It has to have ways of doing things that are as expressive, as sleek,  as ergonomic, performant, fast, and efficient as the other languages. So we have to keep evolving to do that. Now at the same time, we don't like throwing things out because we break people's existing code. What's a programming language designer to do?

We've lived with this conundrum for a while. I think we're starting to circle in on at least a partial solution to it. I can't say for sure that we're going to do this or how we're going to do it, but ... someone like Bill Wagner, who is doing our documentation and working on the C# Standard ...he's very essential in this discussion, said: "How about we try to define modern C#?" If you're coming to C# fresh or even as an existing C# programmer in general—if you have a pretty clean slate, this is the subset that you should be using. If you're outside of that subset it's either because you're trying something fancy like using Span<T> to do efficiency stuff or unsafe code, or it's because you're doing some legacy things. Otherwise, these are the ways you should be doing things.

And then we could reinforce that from the documentation point of view, from a learning point of view, and also from a tooling point of view—we would take these templates and take those little suggestions and say: "Hey, that's kind of an old fashioned thing you're doing there, it would be sleeker to use pattern matching here, why don't you?" In fact, we have plenty of those in place already. We just don't have a coordinated set of features that are like "this is modern C#."

Then that evolves with the language, like when usings come in and some other things fall out of what modern C# is. And now there's a better way to do things. Now, we don't tell you to put usings on top of the file anymore, and we don't have guidelines about whether to prune or not ... that's just gone out of modern C# and now a modern C# programmer doesn't do that anymore.  A sliding window that's current C# might help as long as we don't make it a worse experience to use all of the language. But maybe we can make it an even better experience to use the modern part of the language and can give you more guidance if you're not a veteran or if you don't want to chase down all the reasons for doing one or the other and you just want a recommendation—how should I be doing this? This is what we're currently working on.

I found this very interesting. A C# subset is not a new idea but I think Microsoft working on it is. In the past, I've seen some Microsoft resistance to that idea. It's early days but promising for the future of C#.

Custom deployment layouts for Blazor Web Assembly apps

This week, on the ASP.NET Blog, Javier Calvarro Nelson wrote about new .NET 6 extensibility points that will allow development teams to customize which files to package and publish with Blazor WebAssembly apps. The idea is that you could reuse this as a NuGet package. As Javier notes, this is important because some environments block and download the execution of DLLs from the network for security reasons.

The article lays out how to build the package yourself, but you don't have to. According to Daniel Roth, you can use a prebuilt experimental NuGet package to try it out. To use it, add a reference from your client project, update the server project to add the endpoint, and then publish your app. This is a good first step—hopefully, the end goal is to provide this out of the box.

🌎 Last week in the .NET world

📢 Announcements

• Michael Staib releases Hot Chocolate 12.
• Jiachen Jiang writes about the new nuget.org package details page.
• JetBrains launches the EAP for Resharper 2021.3 and also for Rider 2021.3.
• Javier Calvarro Nelson writes about custom deployment layouts for Blazor WebAssembly apps.

📅 Community and events

• Rodney Littles II writes a difficult, but important, post about his experience on the .NET Foundation board.
• Carol Smith announces Azure credits for open source projects.
• Beau Carnes launches a free Git for Professionals course.
• Henning Dieterichs writes about how the VS Code team made bracket pair colorization 1000x faster.
• Austin Lamb introduces SizeBench, a new tool for analyzing Windows binary size.
• Jeremy Miller writes about how to build efficient web services with Marten v4.

🌎 Web development

• Kristoffer Strube uses Blazor AoT compilation.
• Jon Hilton writes about how he organizes his Blazor components.
• Nancy Young writes about the pros and cons of Tailwind.
• Andrew Lock explores the code behind WebApplicationBuilder in .NET 6.

⛅ The cloud

• Tomasz Pęczek handles transient errors in Azure Durable Functions.
• Mark Heath asks: is it time to start creating C# Azure Functions in isolated mode?.
• Steve Smith writes about running GitHub Actions on demand.

📔 Languages

• Michael Moreno asks: is C# getting too complex?
• Vladimir Pecanac explores events in C#.
• Scott Hanselman writes about implicit usings in .NET 6.
• Khalid Abuhakmeh compresses strings with .NET and C#.
• Jeff Fritz introduces LINQ in C#.
• Thomas Claudius Huber uses global using directives in C# 10.

🔧 Tools

• The Kubernetes Blog discusses how to handle data duplication.
• Davide Bellone tests HttpClientFactory with Moq.
• David Ramel writes how GitHub Copilot AI is spawning OSS Alternatives.
• Christian Gunderman avoids memory leaks in Visual Studio editor extensions.
• Mike Melanson writes about Docker defending their new Docker Desktop pricing, and the Docker Desktop PR campaign continues.
• Tobias Günther creates the perfect commit in Git.
• Milan Milanović writes about CI/CD with Azure DevOps.

🏗 Design, testing, and best practices

• Derek Comartin talks about an always valid domain model.
• Steve Smith groups assertions in tests.
• Thomas Maurer writes about how GitHub partitions its relational databases.
• Jimmy Bogard continues his DDD series with a write-up on encapsulating collections.
• Peter Vogel continues his series on unit testing legacy code.

🎤 Podcasts and videos

• The Coding Blocks Podcast talks about transactions in distributed systems.
• .NET Rocks talks to Mark Seemann about code that fits in your head.
• Software Engineering Daily talks about scaling Git for monorepos.
• The ASP.NET Monsters discuss new LINQ methods in .NET 6.
• Azure Friday walks through CosmosDB.
• The Azure DevOps Podcast talks to Anna Hoffman about Azure SQL.

If you're new to C# and aren't familiar with what namespaces are, you can use a namespace keyword to declare scopes that contain a set of related objects. What kind of objects? According to the Microsoft documentation, namespaces can have classes, interfaces, enums, structs, or delegates. By default, the C# compiler adds a default, unnamed namespace for you—typically referred to as the global namespace. When you declare a specific namespace, you can use identifiers present in the global namespace. See the C# docs for details.

So, how can you declare namespaces in C# 9 and earlier? Keeping with my superhero theme with my C# 9 posts, a Superhero.cs class would look like this:

using System;

namespace SuperheroApp.Models
{
   public class Superhero
   {
      public string? FirstName { get; set; }
      public string? LastName { get; set; }
      public string? StreetAddress { get; set; }
      public string? City { get; set; }
      public int? MaxSpeed { get; set; }
   }
}

Even with this simple example, you can see how much space this adds—both horizontally and vertically—with the indents and curly braces. With C# 10, you can make this cleaner with file-scoped namespaces.

Use C# 10 file-scoped namespaces to simplify your code

With C# 10, you can remove the curlies and replace it with a semicolon, like this:

namespace SuperheroApp.Models;

public class Superhero
{
   public string? FirstName { get; set; }
   public string? LastName { get; set; }
   public string? StreetAddress { get; set; }
   public string? City { get; set; }
   public int? MaxSpeed { get; set; }
}

If you have using statements in your file, you can have the namespace declaration either before or after it. However, it must come before any other members in a file, like your classes or interfaces. Many code analyzers like StyleCop encourage the use of usings inside namespaces to avoid type confusion.

It's worth noting that as the "file-scoped" naming implies, this applies to any objects in the file—like classes, interfaces, structs, and so on. Also, you are limited to only defining one file-scoped namespace per file. You likely aren't surprised, as most of your files typically only have a single namespace.

Limitations with file-scoped namespaces

Now, let's review what you cannot do with file-scoped namespaces.

Mix traditional namespaces and file-scoped namespaces

If you want to mix a non-C# 10 namespace declaration and a file-scoped namespace, you can't. Here's what you'll see from Visual Studio.

Define multiple file-scoped namespaces

What if you want multiple namespaces in a file like this?

namespace SuperheroApp.Models;

public class Superhero
{
    public string? FirstName { get; set; }
    public string? LastName { get; set; }
    public string? StreetAddress { get; set; }
    public string? City { get; set; }
    public int? MaxSpeed { get; set; }
}

namespace SuperheroApp.Models.Marvel;

public class MarvelSuperhero : Superhero
{
    public string[] MoviesIn { get; set; }
}

As discussed previously, you can only define one file-scoped namespace per file. It won't work.

If you want to accomplish this, you'll need to stay old school and define namespace declarations as you usually have.

namespace SuperheroApp.Models
{
    public class Superhero
    {
        public string? FirstName { get; set; }
        public string? LastName { get; set; }
        public string? StreetAddress { get; set; }
        public string? City { get; set; }
        public int? MaxSpeed { get; set; }
    }
}

namespace SuperheroApp.Models.Marvel
{
    public class MarvelSuperhero : Superhero
    {
        public string[] MoviesIn { get; set; }
    }
}

Nesting namespaces

With traditional namespaces, you can nest them like in the following example.

namespace SuperheroApp.Models
{
    public class Superhero
    {
        public string? FirstName { get; set; }
        public string? LastName { get; set; }
        public string? StreetAddress { get; set; }
        public string? City { get; set; }
        public int? MaxSpeed { get; set; }
    }

    namespace SuperheroApp.Models.Marvel
    {
        public class MarvelSuperhero : Superhero
        {
            public string[] MoviesIn { get; set; }
        }
    }
}

However, you can not do this with file-scoped namespaces. When I try to do this, I'll get another compiler error.

Wrapping up: another way to simplify C# code

If you've been following the last couple of C# releases, you've noticed this isn't the first change to simplify boilerplate code—see positional C# records and top-level statements for a few examples—and it likely won't be the last, either. Changes like this allow you to simplify your programs and cut out boilerplate.

In the next post, I'll continue this theme by writing about global using directives in C# 10. I'll talk to you then.

• Azure Functions .NET 6 support
• .NET Foundation Board election news
• Syncing namespaces in Visual Studio
• Last week in the .NET world

Azure Functions .NET 6 support

Last week, Anthony Chu announced the availability of the public preview for Azure Functions 4.0—which includes .NET 6 support. In case you weren't aware, Azure Functions has two programming models: in-process and isolated. Azure Functions 4.0 supports .NET 6 through the isolated model.

As Anthony states, the isolated model gives you greater control over Functions configuration and allows you to use DI and middleware as you do in your ASP.NET Core apps. Currently, you can only use this from CLI tooling. Soon, there will be support for Visual Studio and Visual Studio closer to the general .NET 6 release date in November (which is when Azure Functions 4.0 will be off public preview and generally available).

Since we're talking about Azure Functions, long-term the in-process model will be retired in favor of the isolated model. As you can see from this diagram I stole from Microsoft, that won't happen until .NET 7 in November 2022.

.NET Foundation Board election news

The results are out for the 2021 .NET Foundation Board elections. Congratulations to the following folks who made the cut:

• Mattias Karlsson
• Frank Odoom
• Rob Prouse
• Javier Lozano (re-elected)

Syncing namespaces in Visual Studio

As Oleg Kyrylchuk mentions, in the last preview of Visual Studio 2022 you can syncronize namespaces to mirror how the folder structure looks in Solution Explorer. This is in preview, but looks to be a cool feature—and should be done with caution, as there isn't currently a way to undo easily.

🌎 Last week in the .NET world

📢 Announcements

• Grace Taylor announces a collection of VS themes.
• The .NET Foundation election results are in.
• On September 30 Microsoft will be hosting a "Let's Learn .NET" on IoT.

📅 Community and events

• The Azure SDK team recaps the September release.
• Steve Smith reviews a new DI book.
• Josef Ottosson created a library that packages convenient configuration methods in .NET Core.
• For community standups, Desktop talks about Hot Reload updates, EF talks about PostgreSQL and EF Core, and ASP.NET talks about how to contribute to the platform.
• The .NET Docs show talks about home automation with Azure Precept.

🌎 Web development

• Nigel Sampson adds cross-cutting concerns to a GraphQL service.
• Cody Merritt Anhorn wires up conditional User-Agent logic with Blazor.
• Scott Hanselman shows how to change a site's Dark Mode based on the user's OS preference, and also writes about unit testing Minimal APIs in .NET 6.
• Anthony Giretti uses Angular and .NET 6 to stream JSON responses.

🥅 The .NET platform

• Matt Eland writes about LINQ .NET 6 improvements.
• Andrew Lock compares the WebApplicationBuilder to the generic host in .NET 6.
• Khalid Abuhakmeh provides some "interesting technology tips."

⛅ The cloud

• Muhammed Saleem works with Azure Table Storage in ASP.NET Core.
• Abhishek Gupta uses the Azure Cosmos DB Linux emulator and VS Code.
• Adam Storr asks: is accessing query string values in Azure Functions hard?
• Cyrille Visser optimizes Azure Cosmos DB queries.
• Anthony Chu announces Azure Functions 4.0 public preview with .NET 6 support.
• Damien Bowden creates Microsoft Teams meetings in ASP.NET Core using Microsoft Graph.

📔 Languages

• Ian Griffiths writes about implicit global using directives in C# 10.
• Davide Bellone uses aliases in C#.
• Thomas Claudius Huber writes about file-scoped namespaces in C# 10.

🔧 Tools

• Michael Shpilt writes about 6 tools to detect and fix performance issues in .NET.
• Sarah Lean looks at the GitHub CLI.
• Elijah Manor lists recent Git branches.
• Jason Gaylord writes about GitHub settings you might not know about.

📱 Xamarin

• Claudio Bernasconi sets up .NET MAUI on Windows.
• Leomaris Reyes gets device information.

🏗 Design, testing, and best practices

• The Netflix Tech Blog writes about A/B testing.
• Daniel Wertheim writes about value objects that are always valid.
• Tariq Siddiqui writes about securing web APIs.
• Bilgin Ibryam compares distributed transaction patterns for microservices.
• Peter Vogel starts writing about unit testing legacy code.
• Andrea Chiarelli compares ID tokens and access tokens.

🎤 Podcasts and videos

• AzureFunBytes talks to Christos Matskas about secretless applications.
• The Azure DevOps Podcast talks to Joe Guadagno about the latest in Azure DevOps.
• The Changelog talks about the business model of open source.
• The Unhandled Exception Podcast talks to Steve Collins about DI in .NET.
• Adventures in .NET talk about advocating for yourself.
• .NET Rocks talks to Zaid Ajaj about F# and JS.
• Merge Conflict recaps .NET 6 RC1, .NET MAUI updates, and more.
• The .NET Core Podcast talks to Davide Bedine about Dapr and .NET microservices.
• Jeff Fritz walks through collections and generics in C#.
• The ASP.NET Monsters process CSV files in C#.
• The On .NET Show talks about Reaqtor.

🔥 My favorites from last week

Announcing .NET 6 Release Candidate 1
Richard Lander

ASP.NET Core updates in .NET 6 Release Candidate 1
Daniel Roth

Migration to ASP.NET Core in .NET 6
David Fowler

Update on .NET Multi-platform App UI (.NET MAUI)
Scott Hunter

Visual Studio 2022 Preview 4 is now available!
Mads Kristensen

As expected, .NET 6 Release Candidate (RC) 1 rolled out last week. It's the first of two RC releases deemed "go-live" ready and supported in production. .NET 6 has been feature-complete for a while now, and as Richard Lander states, for this release the "team has been focused exclusively on quality improvements that resolve functional or performance issues in new features or regressions in existing ones." Still, the blog post is worth a read to understand .NET 6's foundational features.

As for the ASP.NET Core side of things, we're seeing quite a bit. The team is rolling out the ability to render Blazor components from JS, Blazor custom elements (on an experimental basis), the ability to generate Angular and React components with Blazor, .NET to JavaScript streaming, and template improvements—including the ability to opt-in to implicit usings—and much more.

Of course, it wouldn't be an ASP.NET Core release without talking about Minimal APIs. RC1 brings a lot of updates: better support for OpenAPI for defining metadata, parameter binding improvements (like allowing optional parameters in endpoint actions), and the ability to use multiple calls to UseRouting to support more middleware. David Fowler also dropped a nice guide for migrating ASP.NET Core to .NET 6. You'll want to check it out to understand how the new hosting model works.

Have a sad trombone ready? .NET MAUI will not be making it into .NET 6's official release in November, according to a Microsoft Scott. It's now looking like it'll be released in early Q2 of 2022. There was a lot to be done, and a slight delay beats a buggy release any day. You can also check out Scott's post for an overview on features rolled out with .NET MAUI Preview 8.

Going hand-in-hand with the .NET 6 releases, Visual Studio 2022 Preview 4 is now available. This release promises personal/team productivity improvements (like finding files) and thankfully a big update for the Blazor and Razor editors. You can now use VS 2022 to hot reload on file save in ASP.NET Core and also apply changes to CSS live. Check out the blog post for details.

📢 Announcements

HTTP/3 support in .NET 6
Sam Spencer

Along with all the other announcements last week, Sam Spencer writes about HTTP/3 support in .NET 6. As a refresher, Sam explains why HTTP/3 is important: "We have all gone mobile and much of the access is now from phones and tablets using Wi-Fi and cellular connections which can be unreliable. Although HTTP/2 enables multiple streams, they all go over a connection which is TLS encrypted, so if a TCP packet is lost all of the streams are blocked until the data can be recovered. This is known as the head of line blocking problem."

"HTTP/3 solves these problems by using a new underlying connection protocol called QUIC. QUIC uses UDP and has TLS built in, so it’s faster to establish connections as the TLS handshake occurs as part of the connection. Each frame of data is independently encrypted so it no longer has the head of line blocking in the case of packet loss."

The RFC for HTTP/3 is not yet finalized and subject to change, but you can start to play around with HTTP/3 and .NET 6 if you're up for getting your hands dirty. You can use the HttpClient as well if you enable a runtime flag. Check out the post for details.

More from last week:

• Some releases: WinUI 2.7 is out, Dapr v1.4 is now out, and so is Uno Platform 3.10. Also, CoreWCF has a new release.
• Leslie Richardson writes about the future of Visual Studio extensibility.
• Vasu Jakkal writes about passwordless personal Microsoft accounts.
• The NuGet folks introduce package source mapping.

📅 Community and events

Announcing the Candidates .NET Foundation Election 2021
Nicole Miller

This post isn't new but if you're a member of the .NET Foundation, they are looking to fill a couple of seats on the Board of Directors. Browse the blog post to learn more about the candidates (Nicole has interviewed each candidate, as well). Voting ends by the end of today (September 20) at 11:59 PST in the USA. (Disclaimer: I was on the Election Board and would love to hear feedback about the process if you have it. We aren't perfect but are trying!)

More from last week:

• The Netflix Tech Blog continues their practical API design series, and also writes about securing at scale.
• For community standups: ASP.NET talks about Blazor .NET 6 RC1 updates, Machine Learning walks through TorchSharp, and .NET Tooling discusses updates for Visual Studio for Mac.
• The .NET Docs Show hosts a .NET IoT AMA.

🌎 Web development

WebSocket per-message compression in ASP.NET Core 6
Tomasz Pęczek

New with ASP.NET Core 6, you can compress WebSocket messages. Tomasz Pęczek has been working with it so far and has a nice post with a GitHub repository you can reference. It ships with a WebSocketAcceptContext object, which includes a DangerousEnableCompression property. Why?

"You might be wondering why such a "scary" property name. It's not because things may fail. If the client doesn't support compressions (or doesn't support compression with specific parameters), the negotiated connection will have compression disabled. It's about security. Similarly to HTTPS, encrypted WebSocket connections are subject to CRIME/BREACH attacks. If you are using encryption, you should be very cautious and not compress sensitive messages."

Also from last week:

• Scott Hanselman writes more about Minimal APIs in .NET 6.
• Visual Studio Magazine confirms that PHP runs the world.
• Thomas Ardal writes about async processing of long-running tasks in ASP.NET Core.
• Khalid Abuhakmeh uses .NET to validate JSON with JSON Schema.
• David Grace works on .NET 6 Blazor updates in Visual Studio 2022.
• Matthew MacDonald asks: is Blazor the future or just another walled garden?

🔧 Tools

Advanced Git Workflow Tips
Khalid Abuhakmeh

Over at the JetBrains blog, Khalid Abuhakmeh writes about ways to make working with Git easier, armed with some JetBrains Rider tips as well. I learned about cleaning your repository of non-tracked artifacts by using git clean -xdf. An irreversible command, you can use it to prevent folder bloat that occurs in new repos when you're working with non-tracked files like dependencies and build items.

• Chinedu Imoh introduces GitHub Codespaces.
• Khalid Abuhakmeh offers advanced Git workflow tips.
• Ryan Staatz writes about 5 things developers need to know about Kubernetes management.
• Davide Bellone customizes fields generation in Visual Studio 2019.
• Patrick Smacchia debugs a .NET App on Linux from Windows Visual Studio with WSL.

🏗 Design, testing, and best practices

• Anwar Al Jahwari works on the Strategy pattern.
• Steve Fenton offers a perspective on the laws of software development.
• Steve Smith asks: should controllers reference repositories or services?
• Mahesh Chand offers some productivity tips.

⛅ The cloud

• Brian Weeteling writes about semantic search with Azure Cognitive Search.
• The CNCF asks: is serverless the right way to the cloud?
• Justin Yoo works on MS Graph, Blazor WebAssembly, and Azure Static Web Apps.

🥅 The .NET platform

• Andrew Lock looks inside the ConfigurationManager in .NET 6.
• The Code Maze blog introduces System.Text.Json.

📔 Languages

• Something I missed a while back: Sam Walpole introduces F# for OO developers.
• Maarten Hus writes about pipeline operator possibilities in F#.

📱 Xamarin

• Luis Matos works on password validation rules with Xamarin Forms.
• Almir Vuk writes about the .NET MAUI compatibility packages for the Xamarin Community Toolkit.

🎤 Podcasts and Videos

• Coding Blocks discusses Docker licensing, career, and coding questions.
• .NET Rocks talks about going from software developer to software engineer, and The Overflow talks about the roadmap from engineer to manager.
• Merge Conflict discusses how not to monetize an app.
• Adventures in .NET ask: how do you grow?
• The .NET MAUI Podcast provides an update.
• The Working Code Podcast asks: are database transactions overrated?
• The 6-Figure Developer Podcast talks to Jesse Liberty about Git.
• The Unhandled Exception Podcast talks about Git with Jesse Liberty and James World.
• The Changelog discusses GitHub Codespaces.
• The Azure DevOps Podcast talks to Daniel Roth about web dev on .NET 6.
• The ASP.NET Monsters walk through DateOnly and TimeOnly in .NET 6.
• The On .NET Show discusses accepting online payments with Stripe and performance and load testing with k6.

Happy Monday! Miss me? A few of you said you have, but I'm 60% sure that's sarcasm.

As you know, I took the last month or so off from the newsletter to focus on other things. I know I wasn't exactly specific on why, and appreciate some of you reaching out. I wasn't comfortable sharing it at the time, but I needed to take time away to focus on determining the next step in my career. If you've interviewed lately, I'm sure you understand ... it really is a full-time job.  I'm happy to say I've accepted a remote tech lead role for a SaaS company here.

I'm rested and ready, so let's get into it! I'm trying something a little different this week—feel free to let me know what you think.

🔥 My favorite from last week

ASP.NET 6.0 Minimal APIs, why should you care?
Ben Foster

We've talked about Minimal APIs a lot in this newsletter and it's quite the hot topic in the .NET community. An alternative way to write APIs in .NET 6 and beyond, there's a lot of folks wondering if it's suitable for production, or can lead to misuse.

Ben notes: "Minimal simply means that it contains the minimum set of components needed to build HTTP APIs ... It doesn’t mean that the application you build will be simple or not require good design."

"I find that one of the biggest advantages to Minimal APIs is that they make it easier to build APIs in an opinionated way. After many years building HTTP services, I have a preferred approach. With MVC I would replace the built-in validation with Fluent Validation and my controllers were little more than a dispatch call to Mediatr. With Minimal APIs I get even more control. Of course if MVC offers everything you need, then use that."

In a similar vein, Nick Chapsas has a great walkthrough on strategies for building production-ready Minimal APIs. No one expects your API to be in one file, and he shows practical ways to deal with dependencies while leveraging minimal API patterns. Damian Edwards has a nice Twitter thread, as well. As great as these community discussions are, I really think the greatest benefit is getting lost: the performance gains.

📅 Community and events

Increasing developer happiness with GitHub code scanning
Sam Partington

If you work in GitHub, you probably already know that GitHub utilizes code scanning to find security vulnerabilities and errors in your repository. Sam Partington writes about something you might not know: they use CodeQL—their internal code analysis engine—to protect themselves from common coding mistakes.

Here's what Sam says about loopy performance issues: "In addition to protecting against missing error checking, we also want to keep our database-querying code performant. N+1 queries are a common performance issue. This is where some expensive operation is performed once for every member of a set, so the code will get slower as the number of items increases. Database calls in a loop are often the culprit here; typically, you’ll get better performance from a batch query outside of the loop instead."

"We created a custom CodeQL query ... We filter that list of calls down to those that happen within a loop and fail CI if any are encountered. What’s nice about CodeQL is that we’re not limited to database calls directly within the body of a loop―calls within functions called directly or indirectly from the loop are caught too."

You can check out the post for more details and learn how to use these queries or make your own.

More from last week:

• Simon Bisson writes about how to use the VS Code editor in your own projects.
• The Netflix Tech Blog starts a series on practical API design and also starts writing about their decision-making process.
• The .NET Docs Show talks about micr0 frontends with Blazor.
• For community standups, Entity Framework talks about OSS projects, ASP.NET has an anniversary, .NET MAUI discusses accessibility, and Machine Learning holds office hours.

🌎 Web development

How To Map A Route in an ASP.NET Core MVC application
Khalid Abuhakmeh

If you're new to ASP.NET Core web development, Khalid put together a nice post on how to add an existing endpoint to an existing ASP.NET Core MVC app. Even if you aren't a beginner, you might learn how to resolve sticky routing issues. At the bottom of the post, he has a nice checklist you should consider when adding a new endpoint.

More from last week:

• Ben Foster explores custom model binding with Minimal APIs in .NET 6.
• Thomas Ardal debugs System.FormatException when launching ASP.NET Core.
• Jeremy Morgan builds a small web API with Azure Functions and SQLite.
• Ed Charbeneau works with low-code data grids and Blazor.
• Scott Hanselman works with a Minimal API todo app.

🥅 The .NET platform

Using Source Generators with Blazor components in .NET 6
Andrew Lock

When Andrew was upgrading a Blazor app to .NET 6, he found that source generators that worked in .NET 5 failed to discover Blazor components in his .NET 6 app because of changes to the Razor compilation process.

He writes: "The problem is that my source generators were relying on the output of the Razor compiler in .NET 5 ... My source generator was looking for components in the compilation that are decorated with [RouteAttribute]. With .NET 6, the Razor tooling is a source generator, so there is no 'first step'; the Razor tooling executes at the same time as my source generator. That is great for performance, but it means the files my source generator was relying on (the generated component classes) don't exist when my generator runs."

While this is by design, Andrew has a great post underlying the issue and potential workarounds.

More from last week:

• Mark Downie writes about his favorite improvements in .NET 6.
• Sergey Vasiliev writes about optimizing .NET apps.
• Paweł Szydziak writes cleaner, safer code with SonarQube, Docker, and .NET Core.
• Sam Basu writes about how to develop for desktop in 2022, and also about developing for .NET MAUI on macOS.
• Paul Michaels manually parses a JSON string using System.Text.Json.
• Johnson Towoju writes logs to SQL Server using NLog.
• Andrew Lock uses source generators with Blazor components in .NET 6.
• Rick Strahl launches Visual Studio Code cleanly from a .NET app.
• Jiří Činčura calls a C# static constructor multiple times.

⛅ The cloud

Minimal Api in .NET 6 Out Of Process Azure Functions
Adam Storr

With all this talk about Minimal APIs, Adam asks: can I use it with the new out-of-process Azure Functions model in .NET 6?

He says: "Azure Functions with HttpTriggers are similar to ASP.NET Core controller actions in that they handle http requests, have routing, can handle model binding, dependency injection etc. so how could a 'Minimal API' using Azure Functions look?"

More from last week:

• Damien Bowden uses Azure security groups in ASP.NET Core with an Azure B2C identity provider.
• Jon Gallant works with the ChainedTokenCredential in the Azure Identity library.
• Adam Storr uses .NET 6 Minimal APIs with out-of-process Azure Functions.

🔧 Tools

New Improved Attach to Process Dialog Experience
Harshada Hole

With the 2022 update, Visual Studio is improving the debugging experience—included is a new Attach to Process dialog experience.

Harshada says: "We have added command-line details, app pool details, parent/child process tree view, and the select running window from the desktop option in the attach to process dialog. These make it convenient to find the right process you need to attach. Also, the Attach to Process dialog is now asynchronous, making it interactive even when the process list is updating." The post walks through these updates in detail.

More from last week:

• Jeremy Likness looks at the EF Core Azure Cosmos DB provider.
• Harshada Hole writes about the new Attach to Process dialog experience in Visual Studio.
• Ben De St Paer-Gotch goes behind the scenes on Docker Desktop.
• Esteban Solano Granados plays with .NET 6, C# 10, and Docker.

🏗 Design, testing, and best practices

Ship / Show / Ask: A modern branching strategy
Rouan Wilsenach

Rouan says: "Ship/Show/Ask is a branching strategy that combines the features of Pull Requests with the ability to keep shipping changes. Changes are categorized as either Ship (merge into mainline without review), Show (open a pull request for review, but merge into mainline immediately), or Ask (open a pull request for discussion before merging)."

More from last week:

• Liana Martirosyan writes about enabling team learning and boost performance.
• Sagar Nangare writes about measuring user experience in modern applications and infrastructure.
• Neal Ford and Mark Richards talk about the hard parts of software architecture.
• Derek Comartin discusses event-sourced aggregate design.
• Steve Smith refactors to value objects.
• Sam Milbrath writes about holding teams accountable without micromanaging.
• Helen Scott asks: how can you stay ahead of the curve as a developer?
• Rouan Wilsenach writes about a ship / show / ask branching strategy.
• Jeremy Miller writes about integration Testing using the IHost Lifecycle with xUnit.Net.

🎤 Podcasts and Videos

• Serverless Chats discusses serverless for beginners.
• The .NET Core Show talks about DotPurple With Michael Babienco.
• The Changelog talks to a lawyer about GitHub Copilot.
• Technology and Friends talks to Sam Basu about .NET MAUI.
• Visual Studio Toolbox talks about Web Live Preview.
• The ASP.NET Monsters talk about new Git commands.
• Adventures in .NET talk about Jupyter notebooks.
• The On .NET Show migrates apps to modern authentication and processes payments with C# and Stripe.

Your most important resource is time. When non-technical users encounter issues and need your help, how much of this important resource are you spending?

We've all been there: a user reports an issue that often doesn't have the context and details you would like—for example, "the site is slow"—and your support and engineering teams eat up a lot of their time on the back and forth. You might ask the user to send along screenshots of the issue. You might have to get on a call to reproduce the issue—and risk an "it worked differently before" situation. In addition, passing around insecure data can lead to security and compliance issues with your organization.

This painful process provides headaches for everyone. End users don't have an easy way to submit logs securely, support staff wastes a lot of back-and-forth time to reproduce the issue, and engineering teams have trouble understanding the context of the issue and reproducing it successfully.

Have you heard about Fiddler Jam? A relative newcomer to the Telerik Fiddler suite of products, Jam is a solution to help support and development teams troubleshoot remote issues with web applications in a quick, easy and secure fashion. How does it work? Users of your site can use a Chrome extension to share the full context of the issue—capturing network logs, browser console logs and screenshots—and the support team can analyze the data immediately. If needed, developers can reproduce and debug the issue using the Fiddler Everywhere debugging proxy.

When I first learned about Fiddler Jam, I had a question that you might be asking yourself, too: in such a busy market, why should I use Fiddler Jam when I have free tools like a browser's developer tools? In this post, I'll make the case for Fiddler Jam in three different ways.

Users Can Easily Send Issue Information

When getting issue details from a user, you'll lack appropriate context—whether users call you, open a support ticket or email screenshots. You're now left with putting together a puzzle from what you're told and what your telemetry tells you. While it's relatively easy to know when an API service is down, what about a stubborn click event that isn't logged?

With Fiddler Jam, it's easy to allow non-technical users to provide context around the issue. In many cases, users can become frustrated to spend so much time reproducing an issue for you when they are already frustrated that things aren't working. With a couple of button clicks, users can provide the complete context of their interaction with your web app.

After asking users to download the Fiddler Jam Chrome extension—which you can use with Google Chrome and Microsoft Edge—users will see a Fiddler Jam icon next to the browser's address bar. Users can then click the icon to start capturing the issue.

Robust Security Practices are Built-In

By default, Fiddler Jam also handles the work of sending data securely. If you review the Advanced Options in the Chrome extension, you'll see a few options you can configure based on your security needs. All options are enabled by default.

• Take screenshots while capturing - This option adds a screenshot from the active Chrome tab. If the screen shows sensitive data, consider disabling it.
• Capture console - This option records any developer console outputs. Again, consider disabling this if your logs have sensitive information.
• Mask cookies - This option masks cookie values so that they aren't visible in the logs. The cookie names will still be visible.
• Mask post data - This option masks data sent along in a POST request, like form information.
• Disable cache - This option asks the browser to skip network requests cache and downloads fresh content from the server

After users capture a session, they can share the session using a public link or Password Protection.

The password-protected logs are secured with AES-CTR encryption, and all logs are stored in the cloud. The Fiddler Jam team won't have access to (and can't recover) password-protected log content. See the Fiddler Jam documentation for details.

Use Powerful Tooling to Review the Entire Context Quickly

With Fiddler Jam, you can use various tooling options to make the most of the data. When a user shares a link, you'll be sent to the Telerik Fiddler Jam dashboard for a detailed view of the logs and information on the request—like headers and request/response bodies. Here's how it looks when I'm looking at a server error, where I have Something bad happened as a response. (I suppose it is an accurate statement but could use more investigation.)

By default, I can also look at user actions. I can look at the button press that initiated the call to the server.

In future versions, Fiddler Jam will take screenshots of more user actions like inputs and scroll events. These actions are stored in the cloud at no additional cost to you. It's one of my favorite features. There's no guessing of what a user said they did and what really happened. It's all here.

The data comes in the format of an HTTP Archive (HAR) file, which is an industry-standard JSON-formatted file that saves HTTP performance data. You can download the HAR file for further inspection and even load the HAR file for mocking. To be clear, this is not the mocking my team does to me when I introduce a bug to the codebase. Instead, Jam sends the data to the Chrome extension, where you can load a session in the browser.

Finally, the engineering team can open the session in Fiddler Everywhere for further investigation. With Fiddler Everywhere's powerful capabilities, you can even replay requests from a user's session!

Summary

In this post, I've shown you how Fiddler Jam provides robust capabilities to help you reproduce and resolve issues quickly. More than just another set of developer tools, it's a full end-to-end troubleshooting solution designed to work well for users, support, and engineering alike. Get started with Fiddler Jam today by going to the Fiddler Jam site and signing up for a free 14-day trial.

• Let's go on a community blog tour
• Did you know?
• A housekeeping note
• Last week in the .NET world

Let's go on a community blog tour

Every week, I provide a big list of quick links for you to check out. I have them this week as I always do, but I wanted to also talk about five or so community blog posts this week. (To be clear, there are always many more great posts from the community that deserves special recognition. These are just some posts that caught my eye this week.)

--

My favorite post this week comes from Josef Ottoson, who describes working with sorting really large files in C#. If you think algorithms have limited real-world applications, think again: after starting with an in-memory application, he compares external merge sort, splitting, and merging. He shows off how he only consumes 32 megabytes when sorting with an external merge sort algorithm, over almost 6 gigabytes with an in-memory solution. (As expected, sorting in memory is a little bit faster.)

--

On the heels of the "Focus on F" .NET Conf, F# creator (and the creator of C# 8 and 9 😉) Don Syme has a Github readme called What operators and symbols does an F# programmer need to know? As someone who's been wanting to learn F# for the last few years now, I appreciate the candor: as with C#, there's much of the language that you don't need on a daily basis.

--

Over at the Visual Studio Code blog, Chris Dias writes about the rise of notebooks. School is starting back up soon, but I'm not talking about those: here I'm talking about docs that contain text, executable code, and its output. It provides interesting use cases for learning and development.

With VS Code, the experience in working with notebooks is a big concern:

To complete the metaphor, notebooks in VS Code have matured from those awkward teen years into (young) adulthood, confident and strong, with a bright future. Working with VS Code notebooks may take a bit of adjustment if you are moving from Jupyter, but we hope it will be worth it in the end. And, as we always try to do, you can customize the experience through settings.

--

We've geeked out about .NET source generators quite a few times in this space. To that end, last week Khalid Abuhakmeh writes about using them to retrieve class declarations from a project. He uses a ISyntaxReceiver, which retrieves the class declarations.

--

Jeremy Miller wrote a nice post about testing effectively with or without mocks or stubs. Are you spending most of your time writing effective tests or simulating data with mocks to avoid writing integration tests? With the advancements in networking and containerization, does it need to be an either/or discussion?

He writes:

In the past, we strongly preferred writing “solitary” tests with or without mock objects or other fakes because those tests were reliable and ran fast. That’s still a valid consideration, but I think these days it’s much easier to author more “socialable” tests that might even be using infrastructure like databases or the file system than it was when I originally learned TDD and developer testing. Especially if a team is able to use something like Docker containers to quickly spin up local development environments, I would very strongly recommend writing tests that work through the data layer or call HTTP endpoints in place of pure, Feathers-compliant unit tests.

Did you know?

Did you know that in Visual Studio Code, you can make Integrated Terminal sessions appear as editor tabs, instead of taking up valuable space in the panel? Not me.

Quick housekeeping note

A quick note: The .NET Stacks is taking a brief break until September. Over the next several weeks, my free time will be extremely limited and I won't be able to devote the time. Thanks as always for your support and I'll be back next month.

🌎 Last week in the .NET world

🔥 The Top 3

• Gregor Suttie sets environmental variables in an Azure Function.
• Anthony Giretti writes about record structs in C# 10.
• Jeremy Miller tests with or without mocks or stubs.

📢 Announcements

Over at JetBrains, the v2021.2 releases for dotCover, dotMemory, dotTrace, and dotPeek have arrived. Alexandra Kolesova writes about updates to Rider 2021.2, and Alexander Kurakin writes about updates to ReSharper 2021.2.

📅 Community and events

• In standups this week, ASP.NET talks about logging updates in ASP.NET Core 6 and MAUI discusses the .NET Upgrade Assistant.
• Shameless plug alert: I'll be on David McCarter's "Rockin' the Code World" on Saturday.

🌎 Web development

• Marinko Spasojevic uses Azure Active Directory B2C with Blazor WebAssembly hosted apps.
• Derek Comartin compares using async messages and synchronous requests and responses.

🥅 The .NET platform

• Dennes Torres warns: be careful with the .NET Core folder structure.
• Nick Randolph explores custom validation and multi-language resource loading for validation with INotifyDataErrorInfo for XAML applications.
• Andrew Lock inserts and removes characters using StringBuilder.
• Khalid Abuhakmeh uses source generators to find class declarations.

📔 Languages

• Don Syme writes: what operators and symbols do an F# programmer need to know?
• Marc Clifton explains C# code to non-programmers.
• Matthew Jones explores file-level namespaces in C# 10 and also writes about null parameter checking in C# 10.
• Niels Swimberghe levels up on data structures and algorithms as he writes a generic bubble sort in C#, works with merge sort, quick sort, insertion sort, binary search, the Generic Boyer–Moore–Horspool algorithm, and linear/sequential search.
• Mahesh Chand writes about the DataTable in C#.
• Josef Ottosson sorts really large files with C#.
• Scott Hanselman compares stringly typed and strongly typed.

🔧 Tools

• Justin Chadell introduces heredocs in Dockerfiles.
• Miroslav Shtilianov designs load tests with Test Studio and Fiddler.
• Shawn Wildermuth looks at static site generators.
• Chris Dias writes about the coming age of notebooks.

🏗 Design, testing, and best practices

• Oren Eini writes about "open for extension, closed for modification" as an architectural pattern.
• Beej Burns writes about a fixed vs growth mindset.
• Jimmy Bogard continues writing about domain-driven refactoring.
• George Stocker writes about why contexts matter.
• J.B.Rainsberger writes about BDD.

🎤 Podcasts

• The Coding Blocks podcast talks about the 2021 State of the Developer Ecosystem.
• The Merge Conflict podcast talks to Maddy Leger.

🎥 Videos

• Azure Friday introduces Azure Static Web Apps.
• On .NET talks about immutable collections in C#.

• One big thing: Logging improvements in .NET 6
• The little things: Notes from the community
• Last week in the .NET world

One big thing: Logging improvements in .NET 6

Over the last few months, we've highlighted some big features coming with .NET 6. Inevitably, there are some features that fly under the radar, including various logging improvements that are coming. Let's talk about a few of them.

Announced with Preview 4 at the end of May, .NET will include a new Microsoft.Extensions.Logging compile-time source generator. The Microsoft.Extensions.Logging namespace will expose a LoggerMessageAttribute type that generates "performant logging APIs" at compile-time. (The source code relies on ILogger, thankfully.)

From the blog post:

The source generator is triggered when LoggerMessageAttribute is used on partial logging methods. When triggered, it is either able to autogenerate the implementation of the partial methods it’s decorating, or produce compile-time diagnostics with hints about proper usage. The compile-time logging solution is typically considerably faster at run time than existing logging approaches. It achieves this by eliminating boxing, temporary allocations, and copies to the maximum extent possible.

Rather than using LoggerMessage APIs directly, the .NET team says this approach offers simpler syntax with attributes, the ability to offer warnings as a "guided experience," support for more logging parameters, and more.

As a quick example, let's say I can't talk to an endpoint. I'd configure a Log class like this:

public static partial class Log
{
    [LoggerMessage(EventId = 0, Level = LogLevel.Critical, Message = "Could not reach `{uri}`")]
    public static partial void CouldNotOpenSocket(ILogger logger, string uri);
}

There is much, much more at the Microsoft doc, Compile-time logging source generation.

On the topic of HTTP requests, ASP.NET Core has a couple of new logging improvements worth checking out, too. A big one is the introduction of HTTP logging middleware, which can log information about HTTP requests and responses, including the headers and body. According to the documentation, the middleware logs common properties like path, query, status codes, and headers with a call to LogLevel.Information. The HTTP logging middleware is quite configurable: you can filter logging fields, headers to log (you need to explicitly define the headers to include), media type options, and a log limit for the response body.

This addresses a common use case for web developers. As always, you'll need to keep an eye on possible performance impacts and mask logging sensitive information (like PII data).

Lastly, with .NET 6 Preview 5 the .NET team rolled out subcategories for Kestrel log filtering. Previously, verbose Kestrel logging was quite expensive as all of Kestrel has shared the same category name. There are new categories on top of *.Server.Kestrel, including BadRequests, Connections, Http2, and Http3. This allows you to be more selective on which rules you want to enable. As shown in the blog post, if you only want to filter on bad requests, it's as easy as this:

{
  "Logging": {
    "LogLevel": {
      "Microsoft.AspNetCore.Kestrel.BadRequests": "Debug"
    }
  }
}

If you want to learn more about ASP.NET Core logging improvements in .NET 6, Maryam Ariyan and Sourabh Shirhatti will be talking about it in Tuesday's ASP.NET standup.

The little things: Notes from the community

AutoMapper is a powerful but self-proclaimed "simple little library" for mapping objects. From Shawn Wildermuth on Twitter, Dean Dashwood has written about Three Things I Wish I Knew About AutoMapper Before Starting. It centers around subtleties when working with dependency injection in models, saving changed and nested data, and changing the models. It's actually a GitHub repo with a writeup and some code samples—highly recommended.

Sometimes one sentence does the trick: Cezary Piątek has a nice MsBuild cheatsheet on GitHub.

This week, Mike Hadlow wrote about creating a standalone ConsoleLoggerProvider in C#. If you want to create a standalone provider to avoid working with dependency injection and hosting, Mike found an ... interesting ... design. He develops a simple no-op implementation.

Well, it's been 20 years since the Agile Manifesto, and Al Tenhundfeld celebrates it with the article Agile at 20: The Failed Rebellion. I think we can all agree that (1) everybody wants to claim they are Agile, and (2) Agile is a very, um, flexible word—nobody is really doing Agile (at least according to the Manifesto). He explores why; an interesting read.

🌎 Last week in the .NET world

🔥 The Top 3

• Oren Eini writes that System.Threading.Tasks.Task isn’t an execution unit.
• Andrew Lock continues his deep dive on StringBuilder, and so does Steve Gordon.
• Al Tenhundfeld speaks the truth on Agile.

📢 Announcements

• Dapr v1.3 is now available.
• Michael Hawker introduces the Community Toolkit.
• Uno Platform shows off improvements with 3.9.

📅 Community and events

• Jeremy Miller writes about Marten, the generic host builder in .Net Core, and more.
• Mike Brind is writing a book about Razor Pages.
• Sha Ma writes about GitHub's journey from monoliths to microservices.
• Richard Lander posts a discussion about the .NET open source project.
• Matthew MacDonald asks: what if GitHub Copilot worked like a real programmer?
• The .NET Docs Show talks to Vahid Farahmandian about gRPC and .NET 5.
• For community standups: ASP.NET talks to Isaac Abraham about F#, and Entity Framework talks about OData.
• Check out all the Focus on F# sessions on YouTube.

🌎 Web development

• The Code Maze blog writes about Onion Architecture in ASP.NET Core.
• Damien Bowden secures ASP.NET Core Razor Pages and Web APIs with Azure B2C External and Azure AD internal identities.

🥅 The .NET platform

• Mike Hadlow creates a standalone ConsoleLoggerProvider.
• Santosh Hari uses app secrets in .NET Core console apps.

⛅ The cloud

• April Edwards compares Azure Static Web Apps, Azure WebApps, and Azure Blob Storage Static Sites.
• Mark Heath writes about the serverless sliding scale.
• John Kilmister gets started with serverless SignalR and Azure Functions.
• Paul Michaels configures Cloudflare to work with Azure domains.

📔 Languages

• Anthony Giretti writes about extended property patterns in C# 10.
• Gergely Sinka toggles functionality in C# with feature flags.

🔧 Tools

• David Ramel writes about Entity Framework Core 6.
• Rachel Appel writes about Blazor debugging improvements in Rider 2021.2.
• Khalid Abuhakmeh writes an extension method that parses a redis-cli connection string for the StackExchange.Redis library.
• Dmitry Lyalin writes about hot reload in Visual Studio 2022.
• Kat Cosgrove writes about Kubernetes fundamentals.
• Matthew Jones creates a Dapper helper C# class to generate parameterized SQL.

📱 Xamarin

• Leomaris Reyes reproduces a fashion UI in Xamarin.
• Charlin Agramonte creates an expandable paragraph control in Xamarin.

🏗 Design, testing, and best practices

• Oren Eini writes about flexible business systems.
• Derek Comartin uses a message-driven architecture to decouple a monolith.
• Charles Humble writes about the future of microservices.
• Suzanne Scacca uses heatmaps to audit web design.
• Davide Bellone explores the tradeoffs of performance and clean code.
• Ben Nadel writes about feature flags.
• Jimmy Bogard continues his series on domain-driven refactoring.
• Ian Cartwright, Rob Horn, & James Lewis write about feature parity.
• InfoQ talks to Michael Perry about immutable architecture, the CAP theorem, and CRDTs.

🎤 Podcasts

• The 6-Figure Developer Podcast talks to Bryan Hogan about Polly.
• Adventures in .NET talks about the global reach of .NET.
• The Merge Conflict podcast talks about FOSS and .NET MAUI Web with Ooui.
• The .NET Core Podcast discusses Gremlinq With Daniel Weber.
• The Azure DevOps Podcast talks about what's coming for developers.
• Scott Hanselman talks to Don Syme about F#.
• The Azure Podcast talks about Azure Arc.

🎥 Videos

• The ASP.NET Monsters works on accessibility testing with Playwright and Axe.
• Luis Quintanilla rolls out a nice "intro to F#" video series.
• Shawn Wildermuth talks about changes coming to Startup in .NET 6.
• On .NET talks about ValueTask in C#.

If you follow me on Twitter, you may have heard I got attacked by six bees last week. I'm fine but appreciate some of you reaching out with comments about whether I'm still "buzzing around somewhere" or "minding my own beeswax" or "ooh, that stings" or even sending memes of a guy with a beard made of bees.

Here's what hive I've got for you this week:

• One big thing: Thoughts on GitHub Copilot
• The little things: A new source generator for JSON serialization, F# getting some love
• Last week in the .NET world

One big thing: Thoughts on GitHub Copilot

Have you caught all the buzz about GitHub Copilot? It's been out in private preview for about a month and I've been checking it out. Marketed by GitHub as "your AI pair programmer," it provides predictions for your code—either as a single line or even an entire function. It's based on GPT-3, a "deep-learning model that uses deep learning to produce human like text."

To quote Colin Ebehardt:

Copilot is based on Codex, a new model which is a derivative of GPT3, which has been trained on vast quantities of open source code from GitHub. It is integrated directly with VSCode in order to generate suggestions based on a combination of the current context (i.e. your code), and the ‘knowledge’ it has acquired during the training process.

There's a ton of examples online from amazed developers. For example, you can enter a comment like // Call GitHub API and Copilot will create a function that calls the GitHub API for you. Of course, this led to some snarky comments about AI taking our jobs. If you're concerned about that, I'd ask you to look at some of the code Copilot spits out. It isn't perfect, but it learns from you ... and does an OK job. To quote philosopher Brian Fantana: "60% of the time, it works every time."

Copilot has massive potential to improve developer workflow and efficiency. For example, how many times do you have to ask Google how to do something you haven't done in a while? Let's say you haven't called HttpClient in a while, or you want to read from a CSV file. You search how to do it, find official docs or Stack Overflow, and go back to your editor and do your best. What if you can cut out all that manual work and generate that code in a few keystrokes? You can focus on the problem you're solving and not on "how do I" tasks. As a smart and experienced developer, you'll know that you'll need to understand the code and tweak it as needed. I do worry about those who won't. It's been easy to blindly introduce code since the invention of the Internet, of course, but doing it from your editor cranks it up a few notches.

From Matthew MacDonald's excellent piece on Copilot:

As long as you need to spend effort reviewing every piece of suggested code, and as long as there is no way to separate a rock-solid implementation from something fuzzier and riskier, the value of Copilot drops dramatically. Not only will it save less time, but it risks introducing elementary mistakes that a less experienced programmer might accept, like using float for a currency variable.

This offering—which will eventually be sold by Microsoft—spends a lot of the reputational capital Microsoft has been building with developers since they started embracing open-source software. While it fits with Microsoft's mission to own the developer experience—from GitHub and NPM to Azure and VS Code, just to name a few—I've seen some Microsoft skeptics viewing this as the company cashing in on the goodwill with the community. While you can't be shocked to see a company mining its free service's public data for eventual profit, there are quite a few licensing and legal challenges that need further clarification (saying "the code belongs to you" in its FAQs might not get by a company's legal department).

Even so, I think Copilot will eventually turn into a powerful tool that can help to automate the painful parts of programming.

The little things: A new source generator for JSON serialization, F# getting some love

While it's easy to highlight the new .NET stuff like hot reload and AOT compilation, it's just as important to write about the stuff we do every day: like serializing and deserializing JSON. Is it exciting? No. It is fun? Also no. It's something we do all the time, though—so it was nice to see Microsoft roll out a new System.Text.Json source generator.

We've talked about source generators before, but a refresher: its code that runs during compilation and can produce additional files that are compiled together with the rest of your code. It’s a compilation step that generates code for you based on your code. It creates a lot of possibilities. This provides an alternative for expensive reflection code, which traditionally leads to slow startup and memory issues.

This new source generator works with JsonSerializer (and does not break existing implementations, don't worry). From the post on the topic:

The approach the JSON source generator takes to provide these benefits is to move the runtime inspection of JSON-serializable types to compile-time, where it generates a static model to access data on the types, optimized serialization logic using Utf8JsonWriter directly, or both.

In the end, moving much of this from runtime to compile-time will help with throughput, memory, and assembly trimming capabilities. The trimming is a big one. The generator can shed a lot of unused code and dependencies.

I think the post does a good job of outlining the capabilities and the rationale for introducing yet another set of APIs.

It's been nice to see F# getting some love lately. Microsoft's latest .NET Conf will be Focus on F#, which will take place on Thursday. Last week, the .NET Docs Show held an F# AMA and Microsoft introduced its first F# Learn modules. Even if you're a C# lifer, it's hard to argue against the impact of functional languages such as F#. As C# has spent the last few major releases introducing constructs like pattern matching, records, and features that focus on immutability, these are features languages like F# have enjoyed for years.

As for Focus on F#, there's a lot of nice stuff on the agenda. I'm looking forward to seeing F# creator Don Syme teaching Python creator Guido van Rossum F# from scratch. For more information on F# and its context within the C# ecosystem, I recommend brushing up on my interviews last year with Isaac Abraham and Phillip Carter.

🌎 Last week in the .NET world

🔥 The Top 3

• Matthew MacDonald asks: is GitHub Copilot fatally flawed or the future of software development?
• Dave Brock works with Blazor Error Boundaries.
• Andrew Lock continues his deep dive on StringBuilder.

📢 Announcements

• The Azure SDK team recaps their July release.
• James Montemagno introduces .NET MAUI Essentials.
• JetBrains has released ReSharper 2021.1.5 and Rider 2021.1.5.
• The Azure Portal team provides their June update.
• Layomi Akinrinade introduces the new System.Text.Json source generator.

📅 Community and events

• JetBrains releases The State of Developer Ecosystem 2021.
• Microsoft now has a private preview for Visual Studio 2022 for Mac.
• Microsoft has rolled out some Learn modules on F#.
• The .NET Docs Show hosts an F# AMA.
• Three community standups this week: Desktop provides updates, Machine Learning holds office hours, and ASP.NET continues its architecture discussions.
• Reminder: Focus on F# is on July 29.

🌎 Web development

• Khalid Abuhakmeh works with Blazor and canceling async calls with CancellationTokenSource, and gets started with ASP.NET Core and gRPC.
• Damien Bowden uses an ASP.NET Core IHostedService to run Azure Service Bus subscriptions and consumers.
• Tomasz Pęczek compares async streamed JSON vs NDJSON in .NET 6.
• Marinko Spasojevic uses app roles with Azure AD and Blazor WebAssembly hosted apps.
• Hassan Habib works with OData in ASP.NET Core 6.
• Nikhil Mohan advocates for gRPC.
• Mike Brind works on CSS isolation for Razor Pages.
• Jon Hilton uses Refit with Blazor.
• Bruno Sonnino transforms an ASP.NET Core MVC app into a PWA.

🥅 The .NET platform

Mike Hadlow creates an Microsoft.Extensions.DependencyInjection object graph writer.

⛅ The cloud

• Thomas Maurer writes about getting started with Azure Arc.
• Matias Quaranta uses Cosmos DB as an ASP.NET session state and caching provider.

📔 Languages

• Anthony Giretti writes about constant interpolated strings in C# 10, uses C# 10 to mix declarations and expressions in deconstruction, and seals overridden ToString() method on records.
• Chris Noring writes about getting started with F#.

🔧 Tools

• Sayed Hashimi designs Web Forms apps with Web Live Preview in Visual Studio 2022.
• Gergely Sinka uses Elasticsearch for .NET.
• Ivan Porta explores Azure Pipelines YAML templates.
• Charris Herrera writes about the top Visual Studio profiling tools.
• Niels Swimberghe proxies phone numbers with Twilio Programmable Voice and Twilio Functions.

📱 Xamarin

• Dotnetsafer recaps some new MAUI features.
• Giorgi Dalakishvili works on Xamarin Forms auth with PKCE.

🏗 Design, testing, and best practices

• Over at martinfowler.com, they write about patterns of legacy displacement and a discussion about extracting product lines.
• Patrick Smacchia writes about best practices for code reviews.
• Peter Vogel writes about the 4 truths of testing.
• Davide Bellone has another clean coding tip.
• Swizec Teller writes about reading Software Engineering at Google.
• Jimmy Bogard continues writing about domain-driven refactoring.
• Richard Lander hosts a discussion about skills and learning.

🎤 Podcasts

• The 6-Figure Developer podcast talks about Comet and .NET MAUI with James Clancey.
• The Coding Blocks podcast talks about GitHub Copilot.
• The Working Code podcast asks: what comes after senior developer?
• The AWS Developers Podcast talks about productive dev environments.
• The Azure Podcast talks to Daria Grigoriu about Azure Static Web Apps.
• Coding After Work talks to Egil Hansen about bUnit and TDD.

🎥 Videos

• Learn Live works with Microsoft Identity.
• The On .NET Show talks about exhaustive case guards in C# and functional-first programming.

Here's what we have going on in #58:

• One big thing: 6 things about .NET 6 Preview 6
• The little things: Visual Studio 2022 Preview 2, abstracting Kubernetes
• Last week in the .NET world

One big thing: 6 things about .NET 6 Preview 6

Last week, the .NET team rolled out .NET 6 Preview 6. Richard Lander has the main blog post.  Dan Roth writes about ASP.NET Core updates, Jeremy Likness updates us on EF Core 6, and David Ortinau covers .NET MAUI. Preview 6 is the second to last preview release of .NET 6. It appears to be a smaller release, with Preview 7 being bigger, as it's the last preview release.  .NET 6 will end up with seven preview releases, then two RC releases (the latter of which should come with go-live licenses).

The releases will be winding down soon, as Richard Lander says: "We’ll soon be addressing only the most pressing feedback, approaching the same bug bar that we use for servicing releases. If you’ve been holding on to some feedback or have yet to try .NET 6, please do now. It’s your last chance to influence the release."

If you want the full details, you can check out the links above—as for me, I'd like to highlight six things that caught my eye.

Sync-over-async thread performance. The sync-over-async pattern—which means using synchronous functionality asynchronously—is a common source of performance degradation and thread starvation. A new change in Preview 6 will improve the rate of default thread injection when the only blocking work on the thread pool is sync-over-async.

New functionality for working with parameters in ASP.NET Core. The ASP.NET Core team released two new features that help when working with components in ASP.NET Core.

The first involves required Blazor component parameters. You do this by using a new [EditorRequired] attribute, like this:

[EditorRequired]
[Parameter]
public string Title { get; set; }

This functionality is enforced at design time and when building—it's important to note it isn't enforced at runtime and won't guarantee the value of the parameter won't be null.

The next feature now supports optional parameters for view component tag helpers in ASP.NET Core. With this update, you no longer need to specify a value for an optional parameter as a tag helper attribute.

WebSocket compression. ASP.NET Core now supports WebSocket compression. This can yield tremendous performance benefits with comes with a ton of caveats. It's disabled by default because enabling it over encrypted connections can make your app subject to attacks. As such, you should only enable it when you know sensitive information isn't being passed around. If that isn't clear enough, the setting is called DangerousEnableCompression. No, seriously.

Minimal API improvements. We've talked about .NET 6 Minimal APIs quite a bit—so much you're probably sick of me talking about them. Even so, the team keeps building them out and Preview 6 brings some enhancements.

First, you can now integrate those APIs with OpenAPI (Swagger) support. You can do this using dependency injection (DI) or middleware. Here's an example using the DI method:

builder.Services.AddEndpointsApiExplorer();

builder.Services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "My API", Description = "My Swagger", Version = "v1" });
});

Second, you can now inject services into the [FromServices] attribute. Previously, you needed to do something like this:

app.MapGet("/movies", async ([FromServices] MovieDbContext db) =>
{
    return await db.Movies.ToListAsync();
});

 And now it's this:

app.MapGet("/movies", async (MovieDbContext db) =>
{
    return await db.Movies.ToListAsync();
});

Pre-convention model configuration. From Preview 6 of EF Core, they've released pre-convention model configuration. From the announcement, Jeremy Likness says it's part of "finding ways to enhance model building so that it can more efficiently figure out what is an entity type and what is not." As more types are mapped, it can be painful to exclude types as entity types (and bringing all that overhead into a model) and reverting types from being entity types in certain situations.

You can now use a ConfigureConventions override to avoid the hassle of configuring every entity. In Jeremy's example, if you want to always store strings as byte arrays, you can use the override instead:

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
  {
      configurationBuilder.Properties<string>()
          .HaveConversion<byte[]>()
          .HaveMaxLength(255);

      configurationBuilder.IgnoreAny<INonPersisted>();
  }

.NET MAUI packaged as workload installation. With .NET 6, Xamarin is merging into the .NET Multi-platform UI (MAUI). MAUI is aiming to be a cross-platform framework for creating mobile and desktop apps with C# and XAML. I don't mention it much here in the newsletter for two reasons—I can't speak about it intelligently because I have no experience with it, and I'm allergic to XAML. The last time I opened a XAML file I got a fever and was in bed for three days.

Even so, there's a lot of great work going into it, and Preview 6 marks the first time MAUI will be shipped as a workload installation. Like the rest of .NET, you can use SDK workloads to enable specific workloads. In MAUI's case, the team is introducing maui, maui-mobile, and maui-desktop workloads, and soon Visual Studio 2022 will include these workloads in the installer.

MAUI is getting close to feature-complete for .NET 6. In this release, the team is rolling out gesture recognizers, clipping region enhancements, and native alerts. Check out the announcement to learn more.

The little things: Visual Studio 2022 Preview 2, abstracting Kubernetes

Since we're on the topic of previews, Visual Studio 2022 Preview 2 is out. Preview 2 is fully localized and ships with over a dozen language packs.

In this update, VS 2022 includes new "Live Preview" experiences with XAML and web apps, which allows you to kiss goodbye to the ancient-feeling recompile-and-run workflow. They are also touting a new Web Live Preview, to allow you to speed up your workflow, with instant updates when working with CSS or data controls. (I suppose we're happy to have it, even if it's an expected feature from modern IDEs these days.) Lastly, this update introduces Force Run, a way to run your app to a specific point that ignores other breakpoints or exceptions. (If you work on C++, check out the post. C++ isn't a .NET language, so I don't write about it here.)

When I see click-baity articles with headlines like Why Developers Should Learn Kubernetes, I can't help but cringe. Thankfully, the article is better than the headline suggests—but even so, it's a lot to suggest developers should know the ins and outs of pods, containers, networking, DNS, and load balancing. There's a difference between asking developers to Shift Left, and making them become SRE experts.

Kubernetes gets a lot of grief: it can be extreme overkill and it incurs a steep learning curve. Even so, containerization (and orchestrating these containers) is here to stay, but we should be providing developers with more abstractions over Kubernetes to make it a more PaaS-like experience. Microsoft is working on their part, and don't be surprised to see Azure (and other clouds) make investments in this space.

🌎 Last week in the .NET world

🔥 The Top 4

• Jimmy Bogard continues his series on domain-driven refactoring.
• Peter Kuhn conveys his thoughts on Microsoft and Blazor.
• Andrew Lock starts a deep dive on StringBuilder.
• Iris Classon writes that the nominations are open for the .NET Foundation Board of Directors 2021 election.

📢 Announcements

• Richard Lander announces .NET 6 Preview 6. Daniel Roth walks through ASP.NET Core updates, Jeremy Likness announces updates for EF Core 6, and David Ortinau writes about .NET MAUI updates for .NET 6 Preview 6.
• Visual Studio 2022 Preview 2 has arrived.
• Kayla Cinnamon rolls out the Windows Terminal Preview 1.10 release.

📅 Community and events

• Joe Guadagno reviews Software Architecture with C# 9 and .NET 5.
• Brandon Minnick writes about the future of the Xamarin Community Toolkit.
• The Focus on F# agenda is out.
• JetBrains is looking for feedback on dotMemory and dotTrace.
• For community standups: .NET Tooling updates on the latest, ASP.NET talks Powered4.tv and Entity Framework visualizes database query plans.
• The .NET Docs Show talks to Isaac Abraham about F#.

🌎 Web development

• Peter Kuhn works on Blazor Server apps in MVC subfolders.
• Jay Krishna Reddy creates and validates a JWT token in .NET 5.0.
• Cody Merritt Anhorn uses Blazor to scroll to a hash anchor on the current page.
• Andrea Chiarelli works on permission-based security for ASP.NET Web APIs.
• Sam Xu introduces an API versioning extension with ASP.NET Core OData 8.
• David Grace uses the button onclick event in Blazor WebAssembly.

🥅 The .NET platform

• Bar Arnon writes about the evolution of an async LINQ operator.
• John Reilly works with Directory.Build.props and C# 9.
• Oren Eini investigates a performance issue.
• Davide Bellone works with the DebuggerDisplay attribute.

⛅ The cloud

• Aaron Powell calls Azure Static Web Apps authenticated API endpoints, works with Azure Functions, F# and CosmosDB Output Bindings, and adds user profiles to Azure Static Web Apps.
• Chloe Condon makes bots with Azure Logic Apps.
• Milan Milanović secures the modern development lifecycle with Microsoft Identity.

📔 Languages

• The Code Maze blog writes about C# tips for code quality and performance.
• Jason Roberts works on init-only property setters in C#.
• Mike Hadlow writes a simple console periodic loop in C#.
• Adam Storr writes about target typed new expressions in C# 9.
• Anthony Giretti writes about global usings in .NET 6 and ASP.NET Core.

🔧 Tools

• Domagoj Vidovic runs through common Git commands.
• Pam Selle tests a command inside a docker container.
• Erik Heemskerk creates reusable build scripts with NUKE components.
• The Kubernetes Blog outlines Kubernetes API and feature removals In 1.22.
• Stephane Eyskens hardens an ASP.NET container running on Kubernetes.
• Steve Tidwell writes how developers should learn Kubernetes.
• Khalid Abuhakmeh shows off a better way to discover APIs with JetBrains Rider.

🏗 Design, testing, and best practices

• Scott Carey writes about how companies got their developers to care about cloud costs.
• Suzanne Scacca writes about building trustworthy websites.
• Al Tenhundfeld talks about writing good Git commit messages.
• Josef Ottoson deals with access tokens in .NET.
• Ron Jeffries asks: Can scrum be fixed?
• Jimmy Bogard continues his series on domain-driven refactoring.
• Paul Michaels tries out mutation testing.

🎤 Podcasts

• The Azure Podcast discusses cloud-native apps.
• The Unhandled Exception podcast talks to Chris Sainty about Blazor.
• The Merge Conflict podcast talks about GitHub Copilot.
• The 6-Figure Developer podcast talks to Jon Douglas.
• Scott Hanselman talks to Maria Naggaga about teaching computer science.
• The No Dogma Podcast talks to David Guida about event sourcing.

🎥 Videos

• Azure Friday talks about several Azure Cosmos DB updates.
• Data Exposed uses SQL Data Sync.
• The On .NET Show discusses commands, queries, and Clean Architecture, positional pattern matching, and explores Spark and ML .NET with F#.
• Technology and Friends talks to Jason Bock about mutation testing.

In Blazor—especially Blazor Server—there is no such thing as a small unhandled exception. When Blazor Server detects an unhandled exception from a component, ASP.NET Core treats it as a fatal exception. Why?

Blazor Server apps implement data processing statefully so that the client and server can have a "long-lived relationship." To accomplish this, Blazor Server creates a circuit server-side, which indicates to the browser how to respond to events and what to render. When an unhandled exception occurs, Blazor Server treats it as a fatal error because the circuit hangs in an undefined state, which can potentially lead to usability or security problems.

As a result, your app is as good as dead, loses its state, and your users are met with an undesirable An unhandled error has occurred message, with a link to reload the page.

In many cases, unhandled exceptions can be out of a developer's control—like when you have an issue with third-party code. From a practical perspective, it's not realistic to assume components will never throw.

Here's an example that a Blazor developer posted on GitHub: let's say I've got two components: MyNicelyWrittenComponent, which I wrote, and a third-party component, BadlyWrittenComponent, which I did not write. (Badly written components rarely identify themselves so well, but I digress.)

<div>
   <MyNicelyWrittenComponent>
   <BadlyWrittenComponent Name="null">
</div>

What if the third-party code is coded like this?

@code {
    [Parameter] public string Name { get; set; }
}
<p>@Name.ToLower()</p>

While I can reasonably expect BadlyWrittenComponent to blow up, the circuit is broken, and I can't salvage MyNicelyWrittenComponent. This begs the question: if I get an unhandled exception from a single component, why should my entire app die? As a Blazor developer, you're left spending a lot of time hacking around this by putting try and catch blocks around every single method of your app, leading to performance issues—especially when thinking about cascading parameters.

If you look at our front-end ecosystems, like React, they use Error Boundaries to catch errors in a component tree and display a fallback UI when a failure occurs for a single component. When this happens, the errors are isolated to the problematic component, and the rest of the application remains functional.

Fear no more: with .NET 6 Preview 4, the ASP.NET Core team introduced Blazor error boundaries. Inspired by Error Boundaries in React, it attempts to catch recoverable errors that can't permanently corrupt state—and like the React feature, it also renders a fallback UI.

From the Error Boundaries design document, the team notes that its primary goals are to allow developers to provide fallback UIs for component subtrees if an exception exists, allow developers to provide cleaner fallback experiences, and provide more fine-grained control over how to handle failures. This capability won't catch all possible exceptions but most common scenarios such as the various lifecycle methods (like OnInitializedAsync, OnParametersSetAsync, and OnAfterRenderAsync ,  and rendering use cases with BuildRenderTree.

In this post, I'll help you understand what Error Boundaries are—and just as importantly, what they aren't.

Get Started: Add Error Boundaries to the Main Layout

To get started, let's use a quick example. Let's say I know a guy—let's call him MAUI Man—that runs a surf shop. In this case, MAUI Man has a Blazor Server app where he sells surfboards and t-shirts. His developer, Ed, wrote a ProductService that retrieves this data.

Let's say the Surfboard API is having problems. Before the error boundary functionality was introduced, my component would fail to process the unhandled exception, and I'd see the typical error message at the bottom of the page.

Let's use the new ErrorBoundary component instead. To do this, navigate to the MainLayout.razor file. (If you aren't familiar, the MainLayout component is your Blazor app's default layout.) In this file, surround the @Body declaration with theErrorBoundary component. If an unhandled exception is thrown, we'll render a fallback error UI.

@inherits LayoutComponentBase

<div class="page">
    <div class="sidebar">
        <NavMenu />
    </div>

    <div class="main">
        <div class="content px-4">
          <ErrorBoundary>
            @Body
          </ErrorBoundary>    
        </div>
    </div>
</div>

On the home page where we call the Surfboard API, we see the default error UI.

The default UI does not include any content other than  An error has occurred. Even in development scenarios, you won't see stack trace information. Later in this post, I'll show you how you can include it.

This UI renders an empty <div> with a blazor-error-boundary CSS class. You can override this in your global styles if desired, or even replace it altogether. In the following example, I can customize my ErrorBoundary component. In this example, I include the @Body inside a RenderFragment called ChildContent. This content displays when no error occurs. Inside ErrorContent—which, for the record, is technically a RenderFragment<Exception>—displays when there's an unhandled error.

<ErrorBoundary>
  <ChildContent>
     @Body
  </ChildContent>
  <ErrorContent>
     <p class="my-custom-class">Whoa, sorry about that! While we fix this problem, buy some shirts!</p>
  </ErrorContent>
</ErrorBoundary> 

How else can you work with the ErrorBoundary? Let's explore.

Exploring the ErrorBoundary Component

Aside from the ChildContent and ErrorContent fragments, the out-of-the-box ErrorBoundary component also provides a CurrentException property—it's an Exception type you can use to get stack trace information. You can use this to add to your default error message (which should only be exposed in development environments for security reasons).

Most importantly, the ErrorBoundary component allows you to call a Recover method, which resets the error boundary to a "non-errored state." By default, the component handles up to 100 errors through its MaximumErrorCount property. The Recover method does three things for you: it resets the component's error count to 0, clears the CurrentException and calls StateHasChanged. The StateHasChanged call notifies components that the state has changed and typically causes your component to be rerendered.

We can use this to browse to our Shirts component when we have an issue with the Surfboard API (or the other way around). Since the boundary is set in the main layout, at first we see the default error UI on every page. We can use the component's Recover method to reset the error boundaries on subsequent page navigations.

@code {
    ErrorBoundary errorBoundary;

    protected override void OnParametersSet()
    {
        errorBoundary?.Recover();
    }
}

As a best practice, you'll typically want to define your error boundaries at a more granular level. Armed with some knowledge about how the ErrorBoundary component works, let's do just that.

Dealing with Bad Data

It's quite common to experience issues with getting and fetching data, whether it's from a database directly or from APIs we're calling (either internal or external APIs).  This can happen for a variety of reasons: from a flaky connection, an API's breaking changes, or just inconsistent data.

In my ShirtList component, we call off to a ShirtService. Here's what I have in ShirtList.razor.cs:

using ErrorBoundaries.Data;
using Microsoft.AspNetCore.Components;
using System.Collections.Generic;
using System.Threading.Tasks;

namespace ErrorBoundaries.Pages
{
    partial class ShirtList : ComponentBase
    {
        public List<Shirt> ShirtProductsList { get; set; } = new List<Shirt>();

        [Inject]
        public IProductService ShirtService { get; set; }

        protected override async Task OnInitializedAsync()
        {
            ShirtProductsList = await ShirtService.GetShirtList();
        }
    }
}

In my ShirtList.razor file, I'm iterating through the ShirtProductsList and displaying it. (If you're worked in ASP.NET Core before you've done this anywhere between five million and ten million times.)

<table class="table">
 <thead>
     <tr>
         <th>ID</th>
         <th>Name</th>
         <th>Color</th>
         <th>Price</th>
     </tr>
  </thead>
  <tbody>
     @foreach (var board in ShirtProductsList)
     {  
         <tr>
            <td>@board.Id</td>
            <td>@board.Name</td>
            <td>@board.Color</td>
            <td>@board.Price</td>
          </tr>   
        }
  </tbody>
</table>

Instead, I can wrap the display in an ErrorBoundary and catch the error to display a message instead. (In this example, to avoid repetition I'll show the <tbody> section for the Razor component.)

<tbody>
   @foreach (var board in ShirtProductsList)
   {
        <ErrorBoundary @key="@board">
            <ChildContent>
                <tr>
                   <td>@board.Id</td>
                   <td>@board.Name</td>
                   <td>@board.Color</td>
                   <td>@board.Price</td>
                 </tr>   
             </ChildContent>
             <ErrorContent>
                 Sorry, I can't show @board.Id because of an internal error.
             </ErrorContent>
         </ErrorBoundary>        
     }
</tbody>

In this situation, the ErrorBoundary can take a @key, which in my case is the individual Surfboard, which lives in the  board variable. The ChildContent will display the data just as before, assuming I don't get any errors. If I encounter any unhandled errors, I'll use ErrorContent to define the contents of the error message. In my case, it provides a more elegant solution than placing generic try and catch statements all over the place.

What Error Boundaries Isn't

I hope this gentle introduction to Blazor Error Boundaries has helped you understand how it all works. We should also talk about which use cases aren't a great fit for Error Boundaries.

Blazor Error Boundaries is not meant to be a global exception handling mechanism for any and all unhandled errors you encounter in your apps. You should be able to log all uncaught exceptions using the ILogger interface.

While you can mark all your components with error boundaries and ignore exceptions, you should take a more nuanced approach to your application's error handling. Error Boundaries are meant for control over your specific component's unhandled exceptions and not a quick way to manage failures throughout your entire application.  

Conclusion

While it's been nice to see the growth of Blazor over the several years, it's also great to see how the ASP.NET Core team isn't afraid to add new features by looking around at other leading front-end libraries—for example, the CSS isolation was inspired by Vue and Error Boundaries is taking cues from what React has done. Not only is Blazor built on open web technologies, but it's also not afraid to look around the community to make things better.

Do you find this useful? Will it help you manage component-specific unhandled exceptions? Let us know in the comments.

Here's what we have this week:

• The big thing: Taking a look at Blazor Error Boundaries
• The little things: .NET Foundation elections, Minimal API improvements, pining to help with OSS?
• Last week in the .NET world

The big thing: Taking a look at Blazor Error Boundaries

This weekend, I finished writing a piece on Blazor error boundaries. It'll be published in a week or two, so here's a preview for you.

Looking at Blazor Server apps: when an unhandled exception occurs, Blazor Server treats it as a fatal error because the circuit hangs in an undefined state, which can potentially lead to usability or security problems. As a result, your app is as good as dead, loses its state, and your users are met with an undesirable An unhandled error has occurred message, with a link to reload the page.

This begs the question: if I get an unhandled exception from a single component, why should my entire app die? As a Blazor developer, you're left spending a lot of time hacking around this by putting try and catch blocks around every single method of your app, leading to performance issues—especially when thinking about cascading parameters. Blazor developers look longingly at React's Error Boundaries and wonder when we get to have nice things.

With .NET 6 Preview 4, you can. Inspired by Error Boundaries in React, it attempts to catch recoverable errors that can't permanently corrupt state—and like the React feature, it also renders a fallback UI. This capability won't catch all possible exceptions but most common scenarios such as the various lifecycle methods (like OnInitializedAsync, OnParametersSetAsync, and OnAfterRenderAsync ,  and rendering use cases with BuildRenderTree.

The new ErrorBoundary component provides a ChildContent fragment (what to display when all goes well), an ErrorContent fragment (what to display when it doesn't), and a CurrentException property so you can capture exception details.

Most importantly, the ErrorBoundary component allows you to call a Recover method, which resets the error boundary to a "non-errored state." By default, the component handles up to 100 errors through its MaximumErrorCount property. The Recover method does three things for you: it resets the component's error count to 0, clears the CurrentException and calls StateHasChanged. The StateHasChanged call notifies components that the state has changed and typically causes your component to be rerendered.

Here's an example:

@code {
    ErrorBoundary errorBoundary;

    protected override void OnParametersSet()
    {
        errorBoundary?.Recover();
    }
}

For another example, let's say you have a component that calls off to an API. Here, I'm getting a list of surfboards. I can wrap the data fetching in an ErrorBoundary.

<tbody>
   @foreach (var board in ShirtProductsList)
   {
        <ErrorBoundary @key="@board">
            <ChildContent>
                <tr>
                   <td>@board.Id</td>
                   <td>@board.Name</td>
                   <td>@board.Color</td>
                   <td>@board.Price</td>
                 </tr>   
             </ChildContent>
             <ErrorContent>
                 Sorry, I can't show @board.Id because of an internal error.
             </ErrorContent>
         </ErrorBoundary>        
     }
</tbody>

Blazor Error Boundaries is not meant to be a global exception handling mechanism for any and all unhandled errors you encounter in your apps. You should be able to log all uncaught exceptions using the ILogger interface.

While you can mark all your components with error boundaries and ignore exceptions, you should take a more nuanced approach to your application's error handling. Error Boundaries are meant for control over your specific component's unhandled exceptions and not a quick way to manage failures throughout your entire application. What do you think?

The little things: .NET Foundation elections, Minimal API improvements, pining to help with a project?

The .NET Foundation will be holding elections next month for two upcoming Board seats. If you've made it to the Elections page, you'll see my face as I'm on the Election Committee.

The .NET Foundation serves the general .NET community by promoting .NET in general, advocating .NET OSS, promoting .NET across a wider community of developers, supporting .NET community events, and offering administrative support to member projects. This is an organization that runs separately from Microsoft.

As a Board member, you'd help to run the .NET Foundation by deciding how the money is spent, decide which projects join the foundation, and much more. If you're interested in running for a seat, let me know and I'll get you started.

We've covered Minimal APIs in .NET 6 a time or two. Prioritizing functions over classes, it's a route to simple APIs that many call ".NET Express"—I like the name because it describes getting right to the point and one of the inspirations.

The examples have mostly been a little "Hello World"-ish. ASP.NET Core architect David Fowler shows that it's coming along:

This Results class looks nice, especially if you aren't a fan of attributes for MVC controllers. I'm interested to see if it can be extended further, and the team is looking into it.

If you're looking to extend model binding by using a single request object, you'll have to wait as it won't make it into .NET 6 (but maybe .NET 7). You can bind directly from the JSON object, but manually dealing with route and query parameters might get a tad unwieldy.

If you're looking to help with some open-source, David Pine could use some help. David has a project called the Azure Cosmos DB Repository .NET SDK, which allows you to use the repository pattern to work with your Cosmos DB instances. It really helps to simplify working with CRUD behavior in Cosmos, especially if you're familiar with the IRepository<T> interface. I find it quite nice, and use it for one of my projects (and have written about it as well).

David is working on a Blazor book for O'Reilly—if you've ever written a book or know someone who has, you won't be surprised to hear he'll need some help with the project. If you're interested in helping out, let him know.

🌎 Last week in the .NET world

🔥 The Top 3

• Claudio Bernasconi works on end-to-end UI testing using SpecFlow.
• Steve Gordon writes about the StringBuilder in two posts.
• Sam Walpole writes about higher-order functions in C#.
• Leomaris Reyes explores automation properties in Xamarin.

📅 Community and events

• Colin Eberhardt writes about GitHub Copilot, and so does Renato Losio.
• Matthew MacDonald asks: is Windows 11 a Better OS for developers?
• In community standups, we have Machine Learning talking about model explainability and Languages & Runtime talks about what's coming up with the next .NET 6 previews.

🌎 Web development

• Matthew Jones continues building a Solitaire game in Blazor.
• Andrew Lock adds authentication to a Blazor Server app using Auth0.
• Vladimir Pecanac writes about things to avoid in your ASP.NET Core controllers.
• Khalid Abuhakmeh decrypts secrets into ASP.NET Core MVC action arguments using action filters.

🥅 The .NET platform

• Jason Bock works on anagrams and prime numbers in .NET.
• Nick Randolph writes about what it means to be a Windows app developer.
• Patrick Smacchia writes about some .NET 6 API updates and improvements.
• Niels Swimberghe creates a Discord Bot using the .NET worker template.

⛅ The cloud

• Aaron Powell continues his series of GraphQL on Azure, creates Azure Static Web Apps with F# and Fable, and also controls the serialization of CosmosDB bindings for Azure Functions.
• Mark Heath writes about dependency injection in Azure Durable Functions.
• Yohan Lasorsa builds a shopping app with Azure Static Web Apps.

📔 Languages

• Davide Bellone compares String.IsNullOrEmpty and String.IsNullOrWhiteSpace.
• Ken Bonny rediscovers implicit casting in C#.
• Nikola M. Zivkovic writes about upcoming C# 10 features.
• Jason Roberts writes about C# 9 foreach support.
• Sanjay Modi writes about SOLID principles in C#.

🔧 Tools

• Mark Downie uses Visual Studio to search objects in a memory dump.
• Raymond Chen asks: what happens if I use a squash instead of a true merge?
• Joe Guadagno tests Web APIs or services with JetBrains Rider.
• Scott Hanselman adds predictive IntelliSense to Windows Terminal.
• Alex Russell writes about Git worktrees.
• Nick Randolph converts an app from .NET MAUI to Uno.

🏗 Design, testing, and best practices

• Sarah Drasner writes about running good meetings.
• Peter Vogel writes about best practices when mocking objects.
• Sean Killeen uses custom comparers in NUnit.
• The Overflow writes about the unexpected benefits of mentoring others.
• Derek Comartin talks through a Clean Code architecture example.

🎤 Podcasts

• The Coding Blocks Podcast continues talking about the DDIA book.
• The .NET Rocks Podcast talks to Jeff Richter about Azure APIs.
• Richard Lander talks to the Azure DevOps Podcast.

🎥 Videos

• Shawn Wildermuth explains dependency injection.
• The On .NET Show diagnoses thread pool exhaustion issues in .NET Core apps, discusses Azure Functions with F#, and also talks about the null-coalescing assignment operator in C#.

Happy Monday! Again. I should really come up with a better opening line. Anyway, it's been a pretty crazy week and I haven't had time to dive deep into any topics this week. As such, I'll just be providing you with the links this week.

Also, thanks to the Independence Day holiday in the US, I'll be taking next week off and will be back with a full issue on July 12. See you then!

🌎 Last week in the .NET world

🔥 The Top 3

• Khalid Abuhakmeh writes about HTTP range requests and partial responses with ASP.NET Core.
• Thomas Ardal uploads and resizes an image natively with ASP.NET Core.
• Leomaris Reyes explores keyboard accessibility in Xamarin.

📢 Announcements

• The ML.NET team provides their June update.
• Microsoft is hosting a live Azure Static Web Apps event on Wednesday.

📅 Community and events

• The NuGet Package Explorer is now on the web, thanks to Uno.
• Stack Overflow introduces a Communities platform.
• Mario Rodriguez talks about the new GitHub Issues.
• The .NET Docs Show talks to Isaac Levin about GitHub Codespaces.
• In community standups, ASP.NET talks architecture, Desktop covers all the updates, and Machine Learning discusses AutoML.

🌎 Web development

• Sam Basu writes about Blazor on WPF.
• Matthew Jones continues building Solitaire in Blazor.
• Marinko Spasojevic uses Azure AD to secure a Blazor WebAssembly standalone app.

🥅 The .NET platform

• Rick Strahl works with locked files when publishing .NET Core apps to IIS with WebDeploy.
• David Ramel provides an update on .NET MAUI Preview 5.
• Nick Randolph writes about Project Reunion and Visual Studio 2022.
• Anirudh Agnihotry writes about package validation.

⛅ The cloud

• The Azure SDK team provides their monthly update.
• Oren Eini writes about the cost of the cloud.
• Aaron Powell writes about Blazor, TypeScript, and Azure Static Web Apps.
• Michael Washington writes about Blazor Azure Communication Services.
• Yohan Lasorsa writes about tips to work with Azure Static Web Apps.

📔 Languages

• Jason Roberts writes about C# 9 pattern matching.
• Andrei Fedotov writes about C# ranges and indexes.

🔧 Tools

• Andrew Lock uses SSH and localhost.run to test GitHub webhooks locally.
• Mark Downie debugs and analyzes dump files in Visual Studio.
• Nicholas Blumhardt writes about customized JSON formatting with Serilog.

🏗 Design, testing, and best practices

• Davide Bellone offers a clean coding tip.
• The Overflow asks: can InnerSource bring open source practices to closed corporate bureaucracies?
• Steve Smith talks about improving method and function clarity.

🎤 Podcasts

• The .NET Core Podcast continues its conversation with Harry Bellamy.
• The 6-Figure Developer Podcast talks about sustainable OSS with Rockford Lhotka.
• The Azure DevOps Podcast talks about Terminal.Gui.
• The .NET Rocks Podcast talks to Dan North about SOLID and CUPID.
• The Working Code Podcast talks about build vs. buy.
• The Web Rush Podcast talks about building the Static Web Apps CLI with Wassim Chegham.

🎥 Videos

• JetBrains hosts a webinar on getting started with Docker.
• The ASP.NET Monsters work on Playwright Inspector.
• The On .NET Show talks about C# records, discusses using declarations, and builds reactive UIs with Blazor.

• One big thing: .NET 6 Preview 5 has arrived
• The little things: Visual Studio 2022 Preview 1 has arrived, dropping support for older frameworks, Markdown tables extension
• Last week in the .NET world

One big thing: .NET 6 Preview 5 has arrived

Even though it still seems that we're still recovering from Preview 4 announced around Build, it's about that time: .NET 6 Preview 5 arrived last Thursday. While Preview 4 brought a lot of developer productivity and experience features like Minimal APIs and Blazor WebAssembly AOT, Preview 5 is a jam-packed release with a lot of work going towards unification in .NET 6.

A big part of that is SDK workloads—announced in Preview 4— a new .NET SDK feature that enables the .NET team to add support for new application types without increasing the size of the SDK. For example, you may want to include MAUI or Blazor WebAssembly application types as you need them. You can view SDK workloads as a package manager for the .NET SDK—the emphasis on the SDK, as Microsoft's vision of one SDK is coming together.

On top of that, Preview 5 brings NuGet package validation, a lot more Roslyn analyzers, improvements to the Microsoft.Extensions APIs, a new JSON source generator, WebSocket compression, OpenTelemetry support, and much more. What about ASP.NET Core? Hot Reload is enabled by default, improvements to Blazor WebAssembly download size with runtime relinking, faster gets and sets for HTTP headers, and more.

With EF Core, Preview 5 brings the first iteration of compiled models. Much like Blazor WebAssembly ahead-of-time (AOT) compilation, the compiled models functionality addresses increasing your startup time. As Jeremy Likness notes: "If startup time for your application is important and your EF Core model contains hundreds or thousands of entities, properties, and relationships, this is one release you don’t want to ignore."

The EF team is reporting 10x performance gains using compiled models. How does this work? When EF creates a context, it creates and compiles delegates to set the table properties. This gives you the ability to query properties right away. Using lazy initialization, EF Core only is accessed when needed. You'll want to check out the blog post for an in-depth discussion of all that's involved. While a fast startup time won't get any complaints, keep in mind that global query filters, lazy loading proxies, change tracking proxies, and IModelCacheKeyFactory implementations aren't supported yet.

If mobile/desktop development is your jam, you'll also want to check out MAUI updates for Preview 5.

The little things: Visual Studio 2022 Preview 1 is here, dropping support for older frameworks, Markdown tables extension

After much fanfare about 64-bit support, Visual Studio 2022 Preview 1 is now here and available for you to try out. By all accounts, it seems to be smooth and snappy—you know, as it should be—and can be installed with earlier versions of Visual Studio. You can check out the Visual Studio 2022 roadmap to see what's coming next.

The 64 bits are getting most of the buzz, but you also may have missed support for IntelliCode completions. These updates complete code for you, sometimes even whole lines of code. Based on your context, it'll predict the next part of code to write, and gives you the option to Tab to accept the changes. Mark Wilson-Thomas mentions this is done by combining a "rich knowledge of your coding context" and also a transformer model that is trained on around half a million public open-source GitHub repositories.

Here's a quick example of me testing it out:

In another example, I wrote a function to print out the first name and last name—it suggested I concatenated the strings together. (I would have preferred string interpolation, but I digress.) Then, as I did a WriteLine call, it suggested I use the method I just wrote.

The .NET team is embarking on an effort to drop older framework versions. While dropping frameworks can be a breaking change, building for every framework version increases complexity and size. The team worked around this by harvesting—building for current frameworks but downloading a package's earlier version and harvest binaries for earlier frameworks. This allows you to update without the worry of losing a framework version, but you won't get any fixes or features from these binaries.

Starting with .NET 6 Preview 5, the .NET team will no longer harvest to ensure support for all assets. This means they are dropping support for frameworks older than .NET Framework 4.6.1, .NET Core 3.1, and .NET Standard 2.0.

As Richard Lander writes:

If you’re currently referencing an impacted package from an earlier framework, you’ll no longer be able to update the referenced package to a later version. Your choice is to either retarget your project to a later framework version or not updating the referenced package (which is generally not a huge take back because you’re already consuming a frozen binary anyways).

Here's something I learned this week: there's a Markdown Tables extension in Visual Studio Code. Who do I talk to about refunding all my time spent tweaking Markdown tables?

🌎 Last week in the .NET world

It's another busy week with new preview releases for .NET and Visual Studio.

🔥 The Top 5

• .NET 6 Preview 5 is out: Richard Lander announces it, Daniel Roth writes about ASP.NET Core updates, Jeremy Likness covers EF Core, and David Ortinau covers .NET MAUI.
• Visual Studio 2022 Preview 1 is now available, and so is 2019 16.11 Preview 2.
• David Pine writes about building SPAs with Blazor.
• Matthew MacDonald writes about the new VS Code Remote Repositories extension.
• Charlin Agramonte explores drag-and-drop in Xamarin.

📢 Announcements

• Scott Hanselman introduces dotnet repl.
• Mika Dumont shares what's new with Roslyn.
• The Uno Platform introduces the 3.8 release.

📅 Community and events

• The next .NET Conf, on July 29, will have an F# focus.
• Jon Skeet has a new book.
• The .NET Docs Show talks to Konrad Kokosa.
• For community standups: Tooling previews Hot Reload for WinForms and WPF, Entity Framework discusses Azure Cosmos DB and EF Core, and ASP.NET builds Teams apps using Blazor.

🌎 Web development

• Mahesh Sabnis works with state management in Blazor apps.
• Jignesh Trivedi works on event handling in Blazor.
• Dave Brock updates a Blazor WebAssembly app from .NET 5 to .NET 6 and writes about REST API versioning in ASP.NET Core.
• Marinko Spasojevic uses Dapper with ASP.NET Core Web API.
• Matthew Jones continues his Solitaire in Blazor series.

🥅 The .NET platform

• Ben Watson writes about Bing migrating their Workflow Engine to .NET 5.
• David Ramel writes about Project Reunion updates.
• Richard Lander mediates a conversation about networking and diagnostics.
• Adam Storr sets content for HttpClient testing with JSON.NET and System.Text.Json.
• Daniel Gomez Jaramillo writes about hot reload for .NET developers.
• Varun Setia describes a new programming model for handling JSON in .NET 6.
• Thomas Ardal shows a name and profile photo with .NET and Gravatar.
• Patrick Smacchia logically names embedded resources in a .csproj file.
• Rick Strahl runs .NET Core apps on a framework other than a compiled version.

⛅ The cloud

• David Ramel writes about .NET 6 support on Azure Functions.
• John Reilly works with Azure Functions and .NET 5.
• Davide Bellone compares queues and topics in Azure Service Bus.
• Hugo G Fernandez R creates a RESTful API with automatic documentation on Azure App Service.

📔 Languages

• Khalid Abuhakmeh writes about C# pattern matching.
• Niels Rasmussen goes deep on record structs in C# 10.

🔧 Tools

• Mitchel Sellers works on DI, async, and HangFire for background processing.
• David Ramel writes about C# scripting.
• Mark Wilson-Thomas writes about IntelliCode completions in Visual Studio.

🏗 Design, testing, and best practices

• Steve Smith writes about prioritizing and microservices.
• Derek Comartin talks about leveraging event-driven architecture for the real-time web.
• David Adsit compares TDD and BDD.
• Anwar Al Jahwari writes about the Interface Segregation Principle.

🎤 Podcasts

• .NET Rocks talks about open source in the enterprise.
• The .NET Core Podcast discusses greenfield and brownfield in .NET with Harry Bellamy.

🎥 Videos

• On .NET discusses clustering in Orleans, works with Azure AD B2C in ASP.NET, talks about using Blazor with Tailwind CSS, gets started with Azure Static Web Apps, and talks about the null coalescing operator in C#.
• Visual Studio Toolbox continues a discussion on async debugging.

Our industry's advancements in agile methodologies, DevOps, and even cloud engineering have brought a key capability to focus on: shared responsibility.

If you've been a developer for a while, you might remember throwing operation problems to an Ops team, testing to a QA team, and so on. These days, developing applications isn't just about developing applications. When developers are invested in the entire lifecycle of the application process, it results in a more invested and productive team.

This doesn't come without drawbacks, of course. While having specialists in those areas will always have value—and seeing these specialists on the development team can be tremendously helpful—developers can feel overwhelmed with all they need to take on. I often see this when it comes to automated testing. As developers, we know we need to test our code, but how far should we take it? After a certain point, isn't the crafting of automated tests the responsibility of QA?

The answer: it's everyone's responsibility and not something you should throw over the wall to your QA department (if you're lucky enough to have one). This post attempts to cut through the noise and showcase best practices that will help you craft better automated tests.

Defining Automated Testing

When I talk about automated tests, I'm referring to a process that uses tools to execute predefined tests based on predetermined events. This isn't meant to be an article focused on differentiating concepts like unit testing or integration testing—if they are scheduled or triggered based on events (like checking in code to the main branch), these are both automated tests.

As a result of having an automated testing pipeline, you can confidently ship low-risk releases and ship better products with higher quality. Of course, automated testing isn't a magic wand—but done appropriately, it can give your team confidence that you're shipping a quality product.

Decide Which Tests to Automate

It isn't practical to say that you want to automate all your test cases. In a perfect world, would you want to? Sure. This isn't a perfect world: you have lots to get done, and you can't expect to test everything. Also, many of your tests need human judgment and intervention.

How often do you need to repeat your test? Is it something that is rarely encountered and only done a few times? A manual test should be fine. However, if tests need to be run frequently, it's a good candidate for an automated test.

Here are some more scenarios to help you identify good candidates for automated tests:

• When tested manually, it is hard to get right? Do folks spend a lot of time setting up conditions to test manually?
• Does it cause human error?
• Do tests need to be integrated across multiple builds?
• Do you require large data sets for performing the same actions on your tests?
• Does the test cover frequent, high-risk, and hot code paths in your application?

Test Early, Often, and Frequently

Your test strategy should be an early consideration and not an afterthought. If you're on a three-week sprint cycle and you're repeatedly rushing to write, fix, or update your tests on the third week, you're headed for trouble. When this happens, teams often rush to get the tests working—you'll see tests filled with inadequate test conditions and messy workarounds.

When you make automated testing an important consideration, you can run tests frequently and detect issues as they arise. In the long run, this will save a lot of time—plus, you'd much rather fix issues early than have an angry customer file a production issue because your team didn't give automated testing the attention it deserved.

Consistently Evaluate Valid and Accurate Results

To that end, your team should always be comfortable knowing your tests are consistent, accurate, and repeatable. Does the team check-in code without ensuring that previous testing is still accurate?  Saying all the tests pass is not the same as saying that the tests are accurate. When it comes to unit testing, in many automated CI/CD systems, you can integrate build checks to ensure code coverage does not consistently drop whenever new features enter the codebase.

If tests are glitchy or unstable, take the time to understand why and not repeatedly manually restart runs because sometimes it works and sometimes it doesn't. If needed, remove these tests until you can resolve these issues.

Ensure Quality Test Result Reporting

What good is an automated test suite if you don't have an easy way to detect, discover, and resolve issues? When a test fails, development teams should be alerted immediately. While the team might not know how to fix it right away, they should know where to look, thanks to having clearly named tests and error messages, robust tools, and a solid reporting infrastructure. Developers should then spend their time resolving issues and not going in circles to understand what the issue is and where it lies.

Pick The Right Tool

Automated testing can become more manageable with the right tools. So I hope you're sitting down for this: I recommend Telerik Test Studio. With Telerik Test Studio, everyone can and drive value from your testing footprint: whether it's developers, QA, or even your pointy-haired bosses.

Developers can use the Test Studio Dev Edition to automate your complex .NET applications right from Visual Studio. QA engineers can use Test Studio Standalone to facilitate developing functional UI testing. Finally, when you're done telling your managers, "I'm not slacking, I'm compiling," you can point them to the web-based Executive Dashboard for monitoring test results and building reports.

Happy Monday! Here's what's going on this week:

• The big thing: Putting a bow on .NET 6 date and time updates
• The little things: Have I Been Pwned project updates, VS Code remote repositories extension, App Service support on .NET 6, Azure Functions updates
• Last week in the .NET world

The big thing: Putting a bow on .NET 6 date and time updates

In a previous issue, we briefly spent some time exploring the new date and time APIs in .NET 6. (Despite feedback of the cringy title, I stand behind DateTime might be seeing other people.) In these posts, I passed along the information from various GitHub issues. This week, it was nice to see Matt Johnson-Pint officially write about it in detail on the .NET Blog.

Here's the gist: the .NET team is rolling out new DateOnly and TimeOnly types for .NET 6.

The DateOnly type, if you can believe it, only supports a date—like a year or a month. You might want to use this when you don't need an associated time, like birthdays and anniversaries. With DateOnly Microsoft promises better type safety when you only want dates, serialization improvements, and simplicity when interacting with databases. DateOnly ships with a robust constructor but no deconstructor.

As for TimeOnly, you'd use it only to represent a time of day. Potential use cases are alarm clock times, when a business is open, or recurring appointment times. Why not TimeSpan? Here, TimeOnly is intended for a time of day and not elapsed time. Again, you'll gain type safety and more accuracy when calculating ranges.

There's a lot of chatter in the community asking: why not use Noda Time instead? From the post:

Noda Time is a great example of a high-quality, community developed .NET open source library ... However, we didn’t feel that implementing a Noda-like API in .NET itself was warranted. After careful evaluation, it was decided that it would be better to augment the existing types to fill in the gaps rather than to overhaul and replace them. After all, there are many .NET applications built using the existing DateTime, DateTimeOffset, TimeSpan, and TimeZoneInfo types. The DateOnly and TimeOnly types should feel natural to use along side them.

As an FYI, the new structs aren't supported in Entity Framework Core 6 yet, but you can check out this comment to find a relevant tracking issue. You'll want to check out the post—in addition to the new DateOnly and TimeOnly structs, the .NET team is rolling out time zone enhancements as well.

These changes aren't replacing any DateTime APIs, just augmenting them. So when it comes time for you to switch to .NET 6, do what works for you.

The little things: Have I Been Pwned project updates, VS Code remote repositories extension, Azure Functions updates, App Service support on .NET 6

This week, we'll talk about Have I Been Pwned, a new Visual Studio Code extension, and updates on running Azure Functions and Azure App Service updates on .NET 6.

Have I Been Pwned project updates

You've likely heard of Troy Hunt's Have I Been Pwned project. At the risk of oversimplifying all that Troy does, you can use it to check if your personal data has been compromised by data breaches. With the help of Cloudflare and Azure Functions, he's been able to operate at a tremendous scale with minimum cost. That site is now getting around 1 billion requests a month.

Last August, Troy announced his plans to take HIBP to open source. Recently, Troy wrote that the Pwned Passwords component is now a .NET Foundation project.  You can check out the code at the HaveIBeenPwned organization on GitHub. As a .NET developer, it's a nice way to look at the code and how it all works, especially when it comes to getting hashes and anonymizing requests.

VS Code remote repositories extension

In this space last week, we mentioned a new VS Code extension for Project Tye. Visual Studio Code is at it again with a new Remote Repositories extension. With this extension, you can browse, search, edit, and commit to any remote GitHub repository without a clone. This extension will support Azure DevOps soon as well. (GitHub is the long-term vision, yet Microsoft is consistently releasing these new capabilities to Azure DevOps. For this and other reasons, I'm pretty sure Azure DevOps will outlive me.)

Personally, looking at GitHub repos is good for my learning—both for what to do and what not to do—and there should be a middle ground between browsing github.com and cloning a big repository to my machine. This should help.

Azure Functions updates

Last week, Azure Functions PM Anthony Chu wrote about recent Azure Functions updates. (I'll be interviewing him soon here, so hit me up if you have any other questions.) We've written about some of what he mentioned, but not everything—here's the latest.

• Visual Studio support for .NET 5.0 isolated function apps: Released in May, Visual Studio 2019 16.10 includes full support for .NET 5.0 isolated process Azure Functions apps. You can check out the tutorial.
• You can run .NET 6 on Azure Functions: To do this, you'll need Azure Functions V4—right now, it's limited to a preview release of Azure Functions Core Tools V4. Check out the post, as there are a few caveats to keep in mind. It's early, and there's no official support yet. Microsoft has published a tutorial on writing .NET 6 apps on Azure Functions.

Azure App Service support on .NET 6

In somewhat related Azure development news, you can use .NET 6 Preview bits on Azure App Service—in either Windows or Linux workloads. You can do this through the Azure App Service Early Access Runtime feature. This feature allows you to get the latest version of SDKs for various languages. With Early Access Runtime, you can get access without waiting for a release cycle.

Microsoft is boasting that it's the first time a pre-release stack is publicly available on App Service before the GA release.

🌎 Last week in the .NET world

We've got another busy week with some great content from the developer community.

🔥 The Top 5

• Matt Johnson-Pint writes about Date, Time, and Time Zone Enhancements in .NET 6.
• Claudio Bernasconi works on Blazor component communication and state handling.
• Leomaris Reyes uses Maps with Xamarin Essentials.
• Microsoft announces the new Remote Repositories extension for Visual Studio Code.
• Joseph Guadagno migrates to ASP.NET Core MVC from ASP.NET Framework MVC.

📅 Community and events

• For community standups: ASP.NET talks about Blazor updates, and Machine Learning holds office hours.
• The .NET Docs Show talks to Niels Swimberghe about making calls with Twilio and Blazor WebAssembly.
• Troy Hunt expands the Have I Been Pwned volunteer community.

🌎 Web development

• The Code Maze blog uses Hangfire with ASP.NET Core.
• Matthew Jones starts developing a solitaire game in Blazor.
• Adam Storr extends HttpClient testing with templating.
• Bruno Sonnino explores Minimal APIs in ASP.NET Core.
• Andrea Chiarelli builds ASP.NET CRUD Web APIs.
• Damien Bowden explores integration testing for ASP.NET Core using EF Core Cosmos with XUnit and Azure DevOps.
• Dave Brock writes about minimal APIs in .NET 6.

🥅 The .NET platform

• Jonathan Allen writes about .NET 6 collections improvements.
• Richard Lander hosts a conversation about containers.
• Andrew Lock explores .NET interactive notebooks with VS Code.
• Patrick Smacchia recaps .NET obfuscator tools.
• John Miller develops apps for Microsoft Teams with .NET.
• Abhijit Jana works with command-line arguments and C# 9.0 top-level statements with Visual Studio.

⛅ The cloud

• Anthony Chu writes about what's new with .NET on Azure Functions.
• Chris Noring builds apps locally with the Azure Static Web Apps CLI.
• Dominique St-Amand works on a CosmosDB Linux container for your CI builds.
• Shelton Graves continues his series on working with events in Azure.

📔 Languages

• Matthew MacDonald previews 5 new features in C# 10.
• Davide Bellone writes about how to get the index of an item in a foreach loop.
• Ken Bonny rediscovers implicit casting.

🔧 Tools

• Anant Vernekar integrates Swagger With ASP.NET Core Using Entity Framework.
• Khalid Abuhakmeh writes about JetBrains Rider plugins for ASP.NET Core developers and how to import settings from Visual Studio and VS Code to Rider.
• Wael Kdouh automates deployments of Azure Logic App Using Azure DevOps.
• Jon Gallant uses the GitHub CLI and Git with GitHub Codespaces.
• David Ramel writes about Rider's improvements with Blazor WebAssembly debugging.
• Lauren Del Signore writes about useful Visual Studio extensions for working with Blazor.

🏗 Design, testing, and best practices

• Al Tenhundfeld asks: what makes a good Git commit?
• Mark Hinkle asks: has serverless jumped the shark?
• Steve Smith writes about C# generics best practices.
• Joydip Kanjilal writes about best practices for designing RESTful APIs.

🎤 Podcasts

• The 6-Figure Developer Podcast talks to Guy Royse about Redis.
• The Adventures in .NET Podcast talks about Uno Platform.
• The Xamarin Podcast talks about .NET MAUI.
• Jesse Liberty talks to Jeff Fritz about Blazor and Azure.
• .NET Rocks talks to Jeremy Miller about event sourcing.
• The Coding Blocks Podcast continues talking about the DDIA book.

🎥 Videos

• The ASP.NET Monsters work on local development with Azure Static Web Apps.
• On .NET talks to Scott Addie about feature flags and Azure App Configuration in .NET, sets up observability in Orleans, talks to Ed Charbeneau about Blazor components, and discusses nullable reference types.

When you ship an API, you're inviting developers to consume it based on an agreed-upon contract. So what happens if the contract changes? Let's look at a simple example.

If I call an API with a URL of https://mybandapi.com/api/bands/4, I'll get the following response:

{
  "id": 4,
  "name": "The Eagles, man"
}

Now, let's say I decide to update my API schema with a new field, YearFounded. Here's how the new response looks now:

{
  "id": 4,
  "name": "The Eagles, man",
  "YearFounded": 1971
}

With this new field, existing clients still work. It's a non-breaking change, as existing apps can happily ignore it. You should document the new field in The Long Run, for sure, but it isn't a huge deal at the end of the day.

Let's say you want the name to be instead a collection of names associated with the band, like this:

{
  "id": 4,
  "names": 
  [
    "The Eagles, man",
    "The Eagles"
  ],
  "FoundedYear": 1971
}

You introduced a breaking change. Your consumers expected the name field to be a string value, and now you're returning a collection of strings. As a result, when consumers call the API, their applications will not work as intended, and your users are not going to Take It Easy.

Whether it's a small non-breaking change or one that breaks things, your consumers need to know what to expect. To help manage your evolving APIs, you'll need an API versioning strategy.

Since ASP.NET Core 3.1, Microsoft has provided libraries to help with API versioning. It provides a simple and powerful way to add versioning semantics to your REST services and is also compliant with the Microsoft REST Guidelines. In this post, I'll show you how you can use the Microsoft.AspNetCore.Mvc.Versioning NuGet package to apply API versioning to ASP.NET Core REST web APIs.

We're going to look through various approaches to versioning your APIs and how you can enable the functionality in ASP.NET Core. Which approach should you use? As always, It Depends™. There's no dogmatic "one size fits all" approach to API versioning. Instead, use the approach that works best for your situation.

Get Started

To get started, you'll need to grab the Microsoft.AspNetCore.Mvc.Versioning NuGet package. The easiest way is through the .NET CLI. Execute the following command from your project's directory:

dotnet add package Microsoft.AspNetCore.Mvc.Versioning

With the package installed in your project, you'll need to add the service to ASP.NET Core's dependency injection container. From Startup.ConfigureServices, add the following:

public void ConfigureServices(IServiceCollection services)
{
   services.AddApiVersioning();
   // ..
}

What happens when I make a GET request on https://mybandapi.com/api/bands/4? I'm greeted with the following 400 Bad Request response:

{
    "error": {
        "code": "ApiVersionUnspecified",
        "message": "An API version is required, but was not specified.",
        "innerError": null
    }
}

By default, you need to append ?api-request=1.0 to the URL to get this working, like this:

https://mybandapi.com/api/bands/4?api-request=1.0

This isn't a great developer experience. To help this, we can introduce a default version. If consumers don't explicitly include a version in their request, we'll assume they want to use v1.0. Our library takes in an ApiVersioningOptionstype, which we can use to specify a default version. So you're telling the consumers, "If you don't opt-in to another version, you'll be using v1.0 of our API."

In Startup.ConfigureServices, update your AddApiVersioning code to this:

services.AddApiVersioning(options =>
{
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.DefaultApiVersion = new ApiVersion(1, 0);
});

With this in place, your consumers should be able to call a default version from https://mybandapi.com/api/bands/4.

Introducing Multiple Versions for a Single Endpoint

Let's say we want to work with two versions of our API, 1.0 and 2.0. We can use this by decorating our controller with an ApiVersionAttribute.

[Produces("application/json")]
[Route("api/[controller]")]
[ApiVersion("1.0")]
[ApiVersion("2.0")]
public class BandsController : ControllerBase
{}

Once I do that, I can use the MapToApiVersionAttribute to let ASP.NET Core know which action methods are mapped to my API versions. In my case, I've got two methods wired up to a GET on api/bands, GetById and GetById20.

Here's how the annotations look:

[MapToApiVersion("1.0")]
[HttpGet("{id}")]
public async Task<ActionResult<Band>> GetById(int id)
{}

[MapToApiVersion("2.0")]
[HttpGet("{id}")]
public async Task<ActionResult<Band>> GetById20(int id)
{}

With this, the controller will execute the 1.0 version of the GetById with the normal URI (or /api/bands/4?api-version=1.0) and the controller executes the 2.0 version when the consumer uses https://mybandapi.com/api/bands/4?api-version=2.0.

Now that we're supporting multiple versions, it's a good idea to let your consumers know which versions your endpoints are supporting. To do this, you can use the following code to report API versions to the client.

services.AddApiVersioning(options =>
{
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.DefaultApiVersion = new ApiVersion(1, 0);
    options.ReportApiVersions = true;
});

When you do this, ASP.NET Core provides an api-supported-versions response header that shows which versions an endpoint supports.

By default, the library supports versioning from query strings. I like this method. Your clients can opt-in to new versions when they're ready. And if no version is specified, consumers can rely on the default version.

Of course, this is not the only way to version an API. Aside from query strings, we'll look at other ways you can version your APIs in ASP.NET Core:

• URI/URL path
• Custom request headers
• Media versioning with Accept headers

Versioning with a URI Path

If I want to version with the familiar /api/v{version number} scheme, I can do it easily. Then, from the top of my controller, I can use a RouteAttribute that matches my API version. Here's how my controller annotations look now:

[ApiVersion("1.0")]
[ApiVersion("2.0")]
[Route("api/v{version:apiVersion}/[controller]")]
public class BandsController : ControllerBase
{}

Then, when I call my API from api/v2/bands/4, I will be calling version 2 of my API. While this is a popular method and is easy to set up, it doesn't come without drawbacks. It doesn't imply a default version, so clients might feel forced to update the URIs throughout their apps whenever a change occurs.

Whether it's using a query string or the URI path, Microsoft.AspNetCore.Mvc.Versioning makes it easy to work with versioning from the URI level. Many clients might prefer to do away with URI versioning for various reasons. In these cases, you can use headers.

Custom Request Headers

If you want to leave your URIs alone, you can have consumers pass a version from a request header. For example, if consumers want to use a non-default version of my API, I can have them pass in a X-Api-Version request header value.

When moving to headers, also consider that you're making API access a little more complicated. Instead of hitting a URI, clients need to hit your endpoints programmatically or from API tooling. This might not be a huge jump for your clients, but is something to consider.

To use custom request headers, you can set the library's ApiVersionReader to a HeaderApiVersionReader, then passing in the header name. (If you want to win Trivia Night at the pub, the answer to "What is the default ApiVersionReader?" is "QueryStringApiVersionReader." )

services.AddApiVersioning(options =>
{
   options.DefaultApiVersion = new ApiVersion(2, 0);
   options.AssumeDefaultVersionWhenUnspecified = true;
   options.ReportApiVersions = true;
   options.ApiVersionReader = new HeaderApiVersionReader("X-Api-Version");
});

In Postman, I can pass in an X-Api-Version value to make sure it works. And it does.

Media Versioning with Accept Headers

When a client passes a request to you, they use an Accept header to control the format of the request it can handle. These days, the most common Accept value is the media type of application/json. We can use versioning with our media types, too.

To enable this functionality, change AddApiVersioning to the following:

services.AddApiVersioning(options =>
{
     options.DefaultApiVersion = new ApiVersion(1, 0);
     options.AssumeDefaultVersionWhenUnspecified = true;
     options.ReportApiVersions = true;
     options.ApiVersionReader = new MediaTypeApiVersionReader("v");
});

Clients can then pass along an API version with an Accept header, as follows.

Combining Multiple Approaches

When working with the Microsoft.AspNetCore.Mvc.Versioning NuGet package, you aren't forced into using a single versioning method. For example, you might allow clients to choose between passing in a query string or a request header. The ApiVersionReader supports a static Combine method that allows you to specify multiple ways to read versions.

services.AddApiVersioning(options =>
{
    options.DefaultApiVersion = new ApiVersion(1, 0);
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.ReportApiVersions = true;
    options.ApiVersionReader =
    ApiVersionReader.Combine(
       new HeaderApiVersionReader("X-Api-Version"),
       new QueryStringApiVersionReader("version"));
});

With this in place, clients get v2.0 of our API by calling /api/bands/4?version=2 or specifying a X-Api-Version header value of 2 .

Learn More

This post only scratches the surface—there's so much more you can do with the Microsoft.AspNetCore.Mvc.Versioning NuGet package. For example, you can work with OData and enable a versioned API explorer, enabling you to add versioned documentation to your services. If you don't enjoy decorating your controllers and methods with attributes, you can use the controller conventions approach.

Check out the library's documentation for details, and make sure to read up on known limitations (especially if you have advanced ASP.NET Core routing considerations).

I wanted to see how easily I could upgrade the Blazor project from .NET 5 to .NET 6. With .NET 6 now on Preview 4, it's evolved enough where I'm ready for an upgrade. I was hoping I could double-click the project file, change my client and test projects from net5.0 to net6.0, and be on my way. (I also know I was being very optimistic.)  

After upgrading the TFM, I was able to run the app successfully. Great. I started this app using .NET 5 and its mature API surface, so I didn't expect any issues there.  The interesting part is deploying it to Azure Static Web Apps. Azure Static Web Apps uses the Oryx build system and I wasn't too sure if it supported .NET 6 yet. It does, and it deployed to Azure Static Web Apps on the first try.

What about upgrading Azure Functions to .NET 6?

Recently, the Azure Functions team announced initial support of running Azure Functions on .NET 6. This currently requires running a preview release of Azure Functions Core Tools V4. So, I could get this working locally but the support won't come to Azure Static Web Apps until we get closer to .NET 6 GA in November 2021. I'll upgrade it then. For me, I'd rather upgrade the Blazor project so I can take advantage of things like hot reload, AOT, and JSON serialization improvements.

This week wasn't as crazy as we're recovering from Build, but as always, there's plenty to discuss. Let's get started.

• One big thing: Taking a look at Blazor WebAssembly AOT
• The little things: NuGet improvements in Visual Studio, Tye gets a VS Code extension
• Last week in the .NET world

One big thing: Taking a look at Blazor WebAssembly AOT

With Blazor, you've got two hosting models to consider, Blazor Server and Blazor WebAssembly.

With Blazor Server, your download size isn't a concern. You can leverage server capabilities with all the .NET-compatible APIs, and you can use thin-clients—you will, however, you need to consider the higher latency and scale if you have a lot of concurrent users. (Unless you have a lot of concurrent connections, it likely won't be an issue.)  With Blazor WebAssembly, you can leverage client capabilities and a fully functioning app once the client downloads it. If you want to embrace Jamstack principles with a SPA calling off to serverless APIs (with attractive options like Azure Static Web Apps), Blazor WebAssembly is a nice option. The download size is larger, and apps do take significantly longer to load, though.

In my experience across the community, I do see many Blazor scenarios geared towards Blazor Server. Many times, folks are also packaging an ASP.NET Core API, and the download size and loading times of WebAssembly might be holding people back. "I want to wait until we get AOT," I've heard a lot of people say.  

Last week, with .NET 6 Preview 4, Blazor ahead-of-time compilation (AOT) is finally here. With AOT, you can compile .NET code directly to WebAssembly to help boost runtime performance. Before AOT, Blazor WebAssembly apps run from a .NET IL interpreter, meaning the .NET WebAssembly code is significantly slower than a normal .NET runtime (like with Blazor Server).

I gave it a go using Steve Sanderson's Picture Fixer app featured in Build talks and the .NET 6 Preview 4 release announcement. As mentioned in the announcement, you need to do two things:

• Install the Blazor WebAssembly AOT build tools as an optional .NET SDK workload
• Add <RunAOTCompilation>true</RunAOTCompilation> to your project file

Then, you'll need to publish your application. On my beefy Dell XPS 15 and its 64 gigs of RAM, it took almost 15 minutes to AOT 15 assemblies and use the Emscripten toolchain to do the heavy lifting. The team notes they are working on speeding this up, but it's good to note this wait only occurs during publish time and not local development. With AOT in place, you can see dramatic changes in data-intensive tasks specifically.

As with the decision to go with Blazor Server or Blazor WebAssembly, you need to consider tradeoffs when introducing AOT with your Blazor projects. As AOT-compiled projects are typically double the size, you need to consider the value of trading off load time performance for runtime performance. You can pick and choose when you use AOT, of course, so typical use cases would take a hybrid approach and leveraging AOT specifically for data-intensive tasks.

When Steve Sanderson talked to us a while back, he said:

If we can get Blazor WebAssembly to be faster than JS in typical cases (via AoT compilation, which is very achievable) and somehow simultaneously reduce download sizes to the point of irrelevance, then it would be very much in the interests of even strongly JS-centric teams to reconsider and look at all the other benefits of C#/.NET too.

AOT is a big step in that direction. The size of the .NET runtime will never compare to small JS frameworks, but getting close to download size and performance will be a giant step towards providing a modern, fast SWA solution for folks open to the .NET ecosystem.

NuGet improvements in Visual Studio, Tye gets a VS Code extension

Last week, Christopher Gill announced that Visual Studio is introducing NuGet Package Suggestions in Visual Studio 16.10. With IntelliCode Package Suggestions, NuGet uses your project's metadata—like what packages you have installed and your project type—to suggest packages you might need. Package suggestions are shown in the NuGet Package Manager UI before you enter a search query.

As for the fine print, it currently only works on the project level and does not suggest packages outside of nuget.org. Also, it won't support deprecated packages or ones that are transitively installed.

Also from last week, Microsoft rolled out a Visual Studio Code extension for Tye. If you aren't familiar Project Tye is an open-source project that helps developers work with microservices and distributed applications.

We're seeing a lot of nice updates for Tye, and I wonder when it'll get out of the "it's experimental, things might break" phase. For example, the official repo on GitHub still states: "Project Tye is an open source experiment at the moment. We are using this time to try radical ideas to improve microservices developer productivity and see what works...For the duration of the experiment, consider every part of the tye experience to be volatile." It has a lot of nice use cases with Dapr, for example, and I'd love to see when Microsoft is going to put a ring on it.

🌎 Last week in the .NET world

🔥 The Top 3

• David Pine builds a video chat app with ASP.NET Core 5.0, Angular 11, and Twilio Programmable Video.
• Christopher Gill introduces IntelliCode package suggestions for NuGet in Visual Studio.
• Mark Downie interprets async code in CPU traces.

📢 Announcements

• Jon Galloway announces Visual Studio 2019 for Mac version 8.10.
• Pratik Sanglikar announces the Visual Studio Code extension for Tye.
• Dapr 1.2 is now available.
• Josh Love introduces the Azure Functions extension libraries for the Azure SDK.
• In JetBrains news, Khalid Abuhakmeh introduces real-time inspections in dotMemory Allocation Analysis, Alexander Kurakin announces an EAP for Rider 2021.2 and ReSharper 2021.2, and Cake for Rider 1.0 is released.

📅 Community and events

• Aaron Stannard chimes in on the IdentityServer drama.
• For community standups: Xamarin recaps Build 2021, and Entity Framework introduces EF Core compiled models.
• Stack Overflow was acquired for $1.8 billion.

🌎 Web development

• Hassan Habib builds contextual experiences with Blazor.
• Cody Merritt Anhorn builds a template using Blazor and Contentful CMS.
• David Grace builds a Connect 4 game with Blazor.
• Damien Bowden verifies vaccination data with ASP.NET Core and Mattr.
• Gopi Govindasamy dynamically renders a component in a Blazor app.
• Jon Hilton walks through choosing a Blazor component library.
• Marinko Spasojevic writes about asynchronous programming with async and await in ASP.NET Core.

🥅 The .NET platform

• Kristoffer Strube writes about new LINQ extensions in .NET 6.
• Richard Lander posts a discussion about the .NET type system and about .NET interop.
• Andrew Lock benchmarks various reflection methods for calling a constructor in .NET.
• Christos Matskas writes about secure and minimal APIs using .NET 6, C# 10, and Azure Active Directory.
• Khalid Abuhakmeh works with the PriorityQueue in .NET 6.

⛅ The cloud

• Maarten Balliauw uses custom bindings with the Azure Functions .NET isolated worker.
• Davide Bellone introduces using Azure Service Bus with C#.
• Théo Rémy works on stateful serverless workflows with Azure Durable Functions.
• Thomas Maurer runs cloud-native apps on Azure PaaS anywhere.

🔧 Tools

• Abhijit Jana switches between Git branches and repos in Visual Studio and removes unused references in Visual Studio.
• Nicholas Blumhardt customizes Serilog text output.
• Russell Smith gets started with the Windows Package Manager, and Matthew MacDonald offers his honest appraisal.

📱 Xamarin

• James Montemagno writes about building beautiful apps with Xamarin.
• Luis Matos recaps .NET MAUI Preview 4.
• Sam Basu provides his weekly MAUI update.

🏗 Design, testing, and best practices

• Jimmy Bogard starts a series on domain-driven refactoring.
• Vladimir Khorikov writes about nulls in value objects.
• Derek Comartin talks about the Competing Consumers Pattern.

🎤 Podcasts

• The Overflow talks about observability and OpenTelemetry.
• The 6-Figure Developer podcast talks to Cecil Phillip about Dapr.
• The Azure DevOps Podcast recaps Build 2021, and so does Merge Conflict.
• The No Dogma Podcast talks to Martin Beeby about using .NET on AWS.
• The .NET Core Podcast talks to Tanya Janka about application security.

🎥 Videos

• The ASP.NET Monsters deploys with GitHub Actions.
• On .NET talks about C# string interpolation and async streams.
• Technology and Friends talks to Jeff Wilcox about open source at Microsoft.
• Data Exposed sets up Azure Monitor for SQL Insights.

When developing APIs in ASP.NET Core, you're traditionally forced into using ASP.NET Core MVC. Going against many of the core tenets of .NET Core, MVC projects give you everything and the kitchen sink. After creating a project from the MVC template and noticing all that it contains, you might be thinking: all this to get some products from a database? Unfortunately, with MVC it requires so much ceremony to build an API.

Looking at it another way: if I'm a new developer or a developer looking at .NET for the first time (or after a long break), it's a frustrating experience—not only do I have to learn how to build an API, I have to wrap my head around all I have to do in ASP.NET Core MVC. If I can build services in Node with just a few lines of code, why can't I do it in .NET?

Starting with .NET 6 Preview 4, you can. The ASP.NET team has rolled out Minimal APIs, a new, simple way to build small microservices and HTTP APIs in ASP.NET Core. Minimal APIs hook into ASP.NET Core's hosting and routing capabilities and allow you to build fully functioning APIs with just a few lines of code. This does not replace building APIs with MVC—if you are building complex APIs or prefer MVC, you can keep using it as you always have—but its a nice approach to writing no-frills APIs.

In this post, I'll give you a tour of Minimal APIs. I'll first walk you through how it will work with .NET 6 and C# 10. Then, I'll describe how to start playing with the preview bits today. Finally, we'll look at the path forward.

Write a Minimal API with Three Lines of Code

If you want to create a Minimal API, you can make a simple GET request with just three lines of code.

var app = WebApplication.Create(args);
app.MapGet("/", () => "Hello World!");
await app.RunAsync();

That's it! When I run this code, I'll get a 200 OK response with the following:  

HTTP/1.1 200 OK
Connection: close
Date: Tue, 01 Jun 2021 02:52:42 GMT
Server: Kestrel
Transfer-Encoding: chunked

Hello World!

How is this even possible? Thanks to top-level statements, a welcome C# 9 enhancement, you can execute a program without a namespace declaration, class declaration, or even a Main(string[] args method. This alone saves you nine lines of code. Even without the Main method, we can still infer arguments—the compiler takes care of this for you.

You'll also notice the absence of using statements. This is because by default, in .NET 6, ASP.NET Core will use global usings—a new way to declare your usings in a single file, avoiding the need to declare them in individual source files. I can keep my global usings in a devoted .usings file, as you'll see here:

global using System;
global using System.Net.Http;
global using System.Threading.Tasks;
global using Microsoft.AspNetCore.Builder;
global using Microsoft.Extensions.Hosting;
global using Microsoft.Extensions.DependencyInjection;

If you've worked with Razor files in ASP.NET Core, this is similar to using a _Imports.razor file that allows you to keep @using directives out of your Razor views. Of course, this will be out-of-the-box behavior but doesn't have to replace what you're doing now. Use what works best for you.

Going back to the code, after creating a WebApplication instance, ASP.NET Core uses MapGet to add an endpoint that matches any GET requests to the root of the API. Right now, I'm only returning a string. I can use lambda improvements to C# 10 to pass in a callback—common use cases might be a model or an Entity Framework context. We'll provide a few examples to show off its flexibility.

Use HttpClient with Minimal APIs

If you're writing an API, you're likely using HttpClient to consume APIs yourself. In my case, I'll use the HttpClient to call off to the Ron Swanson Quotes API to get some inspiration. Here's how I can make a async call to make this happen:

var app = WebApplication.Create(args);
app.MapGet("/quote", async () => 
    await new HttpClient().GetStringAsync("https://ron-swanson-quotes.herokuapp.com/v2/quotes"));
await app.RunAsync();

When I execute this response, I'll get a wonderful quote that I will never disagree with:

HTTP/1.1 200 OK
Connection: close
Date: Fri, 04 Jun 2021 11:27:47 GMT
Server: Kestrel
Transfer-Encoding: chunked

["Dear frozen yogurt, you are the celery of desserts. Be ice cream or be nothing. Zero stars."]

In more real-world scenarios, you'll probably call GetFromJsonAsync with a model, but that can be done just as easily. Speaking of models, let's take a look to see how that works.

Work with Models

With just an additional line of code, I can work with a Person record. Records, also a C# 9 feature, are reference types that use value-based equality and help enforce immutability. With positional parameters, you can declare a model in just a line of code. Check this out:

var app = WebApplication.Create(args);
app.MapGet("/person", () => new Person("Bill", "Gates"));
await app.RunAsync();

public record Person(string FirstName, string LastName);

In this case, the model binding is handled for us, as we get this response back:

HTTP/1.1 200 OK
Connection: close
Date: Fri, 04 Jun 2021 11:36:31 GMT
Content-Type: application/json; charset=utf-8
Server: Kestrel
Transfer-Encoding: chunked

{
  "firstName": "Bill",
  "lastName": "Gates"
}

As we get closer to the .NET 6 release, this will likely work with annotations as well, like if I wanted to make my LastName required:

public record Person(string FirstName, [Required] string LastName);

So far, we haven't passed anything to our inline lambdas. If we set a POST endpoint, we can pass in the Person and output what was passed in. (Of course, a more common ideal real-world scenario would be passing in a database context. I'll leave that as an exercise for you, as setting up a database and initializing data is outside the scope of this post.)

var app = WebApplication.Create(args);
app.MapPost("/person", (Person p) => $"We have a new person: {p.FirstName}     {p.LastName}");
await app.RunAsync();

public record Person(string FirstName, string LastName);

When I use a tool such as Fiddler (wink, wink), I'll get the following response:

HTTP/1.1 200 OK
Connection: close
Date: Fri, 04 Jun 2021 11:36:31 GMT
Content-Type: application/json; charset=utf-8
Server: Kestrel
Transfer-Encoding: chunked

We have a new person: Ron Swanson

Use middleware and dependency injection with Minimal APIs

Your production-grade APIs—no offense, Ron Swanson—will need to deal with dependencies and middleware. You can handle this all through your Program.cs file, as there is no Startup file out of the box. When you create a WebApplicationBuilder, you have access to the trusty IServiceCollection to register your services.

Here's a common example, when you want only to show exception details when developing locally.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}

// endpoints

There's nothing against you creating a Startup file yourself as you always have, but you can do it right here in Program.cs as well.

Try Out Minimal APIs Yourself

If you'd like to try out Minimal APIs yourself right now, you have two choices: live on the edge or live on the bleeding edge.

Live On The Edge: Using the Preview Bits

Starting with Preview 4, you can use that release to explore how Minimal APIs work, with a couple of caveats:

• You can't use global usings
• The lambdas will be casted

Both of these are resolved with C# 10, but the Preview 4 bits use C# 9 for now. If you want to use Preview 4, install the latest .NET 6 SDK—I'd also recommend installing the latest Visual Studio 2019 Preview. Here's how our first example would look. (I know, six lines of code. What a drag.)

using System;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.Hosting;

var app = WebApplication.Create(args);
app.MapGet("/", (Func<string>)(() => "Hello World!"));
await app.RunAsync();

If you want to start with an app of your own, you can execute the following from your favorite terminal:

dotnet new web -o MyMinimalApi

Living on the Bleeding Edge: Use C# 10 and the latest compiler tools

If you want to live on the bleeding edge, you can use the latest compiler tools and C# 10.

First, you'll need to add a custom nuget.config to the root of your project to get the latest tools:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <!--To inherit the global NuGet package sources remove the <clear/> line below -->
    <clear />
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
    <add key="dotnet6" value="https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet6/nuget/v3/index.json" />
    <add key="dotnet-tools" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" />
  </packageSources>
</configuration>

In your project file, add the following to use the latest compiler tools and enable the capability for the project to read your global usings from a .usings file:

<ItemGroup>
   <PackageReference Include="Microsoft.Net.Compilers.Toolset" Version="4.0.0-2.21275.18">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
   </PackageReference>
</ItemGroup>

<ItemGroup>
  <Compile Include=".usings" />
</ItemGroup>

Then, you can create and update a .usings file, and you are good to go! I owe a debt of gratitude to Khalid Abuhakmeh and his CsharpTenFeatures repo for assistance. Feel free to refer to that project if you have issues getting the latest tools.

What does this mean for APIs in ASP.NET Core?

If you're new to building APIs in ASP.NET Core, this is likely a welcome improvement. You can worry about building APIs and not all the overhead that comes with MVC.

If you've developed ASP.NET Core APIs for a while, like me, you may be greeting this with both excitement and skepticism. This is great, but does it fit the needs of a production-scale API? And when it does, will it be hard to move over to the robust capabilities of ASP.NET Core MVC?

With Minimal APIs, the goal is to move out core API building capabilities—the ones that only exist in MVC today—and allow them to be used outside of MVC. When extracting these components away to a new paradigm, you can rely on middleware-like performance. Then, if you need to move from inline lambdas to MVC and its classes and controllers, the ASP.NET team plans to provide a smooth migration for you. These are two different roads with a bridge between them.

If you think long-term, Minimal APIs could be the default way to build APIs in ASP.NET Core—in most cases, it's better to start off small and then grow, rather than starting with MVC and not leveraging all its capabilities. Once you need it, it'll be there.

Of course, we've only scratched the service in all you can do with Minimal APIs. I'm interested in what you've built with them. What are your thoughts? Leave a comment below.

But most of all, I'd like to thank all of you for your support. Honestly, this little project started as a way to keep my mind busy during a pandemic lockdown and I really wasn't sure how things would go. (Looking back at the first issue ... that was very evident.) I'm thrilled it's been able to have the impact it has, and I'm grateful to all of you for that.

With all that out of the way, what are we talking about this week? In this extended issue, there's a lot here:  

• Build 2021 recap
• .NET 6 Preview 4 has arrived
• Visual Studio updates
• System.Console in .NET 7

Build 2021 recap

Last week, Microsoft rolled out Build 2021. You can check out the 330 sessions at the Build website, and there's a YouTube playlist at the Microsoft Developer YouTube channel. It's no secret that these days Build is heavy on promoting Azure services, but .NET got a lot of love last week, too.

Your mileage may vary, but my favorite sessions included the application development keynote, a .NET "Ask the Experts" session,  increasing productivity with Visual Studio, microservices with Dapr, modern app development with .NET, and a .NET 6 deep-dive session with Scott Hunter. (Hunter is Microsoft's CSO—the Chief Scott Officer. He also runs .NET.)

I want to call out a few interesting details from that session: updates on C# 10 and a new Blazor FluentUI component library that's taking shape. (There were other nice updates on .NET MAUI and Minimal APIs that we'll surely address in depth in later issues.)

C# 10 updates

In Scott Hunter's talk, Mads Torgersen and Dustin Campbell walked through some updates coming to C# 10. C# 10 looks to be focused on productivity and simplicity features. I want to show off record structs, required object initializers, auto-implemented property improvements, null parameter checking, global usings, and file-scoped namespaces.

Record structs

C# 9 brought us records, which gives you the ability to enforce immutability with the benefits of "value-like" behavior. While the C# 9 records are really just a class under the covers and accessed by reference, the "value-like" behaviors ensure that default equality checking works with your object's data (as opposed to reference equality). A good use case is with DTOs and other objects that benefit from immutability.

With all reference types, though, passing around a lot of records can create a lot of pressure on the garbage collector. If you couple that with using with expressions, copying and GC pressure can become an issue if you go crazy with records. Can we use structs with records? With C# 10, you can with the record struct syntax. It'll behave similarly, with the only key difference being that record structs aren't heap-allocated. This will also work with tuples, expressions, or any other struct types.

Let's look at some code, shall we? Let's say you have a Person record in C# 9:

record Person
{
   public string FirstName { get; init; }
   public string LastName { get; init; }
}

To use a record struct, change it to this:

record struct Person
{
   public string FirstName { get; init; }
   public string LastName { get; init; }
}

The default record declaration will still be a reference type. If you want to make that explicit, you can use the new class struct syntax. They are the same.

Required object initializers

I enjoy the flexibility of object initializers. You can use them to initialize objects however you want: you can initialize just a few properties, in whatever order you want, or none at all! Unfortunately, this flexibility can also bite you in the rear end if you aren't careful.

With C# 10, you can set fields to be required when performing object initialization, like this:

record struct Person
{
   public required string FirstName { get; init; }
   public required string LastName { get; init; }
}

Its early days on this feature, but it might also help to enforce whether types can be instantiated by positional syntax (constructors) or object initialization.

Auto-implemented property improvements

In the Build talk, Dustin and Mads talked about the cliff: let's say you want to change one little thing about an auto-implemented property. The next thing you know, you're creating a backing field, adding bodies for your getters and setters, and you're left wondering why it takes so much work to change one little thing.

With C# 10, you can refer to the auto-generated backing field without all that nonsense. You'll be able to work with a field keyword in your getters, setters, or even both.

record struct Person
{
   public string FirstName { get; init => field = value.Trim(); }
   public string LastName { get; init; }
}

This change provides better encapsulation and fewer lines of boilerplate code.

Null parameter checks

We've seen many nullability improvements over the last few C# releases, but null parameter checking can still be a manual chore—even with null reference types, you have to depend on the caller to do null checks.

With C# 10, this is taken care of with the !! keyword:

public void DoAThing(string text!!)
{
   Console.WriteLine(text);
}

Don't worry, you aren't seeing double—this doesn't mean you're super excited about the text argument. Personally, I'm not a fan of the !!—at this rate, the C# team will need to start inventing new characters—but I am a fan of removing a bunch of this boilerplate nonsense.

Global usings and file-based namespaces

Lastly, the team introduced a few enhancements to help simplify your C# codebase.

With global usings, you can use the global using keywords to signify usings should be accessible throughout every .cs file in your project.

Here's a typical example of using statements you might want to use in your global using file:

global using System;
global using System.Collections.Generic;
global using System.Linq;
global using System.Threading.Tasks;
global using static System.Console;

I wonder if we could use Roslyn analyzers to shake out unused global usings for individual files. Anyway, I think this is a feature I will originally hate, then learn to love. It's nice to see what is being used, but after a while, it's a maintenance headache. This will be nice. (Not to mention ASP.NET Core developers are familiar with a similar approach with Razor files.) In any case, in many files, you might wind up with a global usings file, then individual usings for references that aren't scattered across your projects.

Lastly, the team introduced file-scoped namespaces. It allows you to go from this:

namespace MyNamespace
{
   record Person
   {
      public string FirstName { get; init; }
      public string LastName { get; init; }
   }
}

To this:

namespace MyNamespace;

record Person
{
   public string FirstName { get; init; }
   public string LastName { get; init; }
}

Of course, you could use top-level statements to remove namespaces completely—however, there are plenty of reasons why you don't want to abstract away your namespace declarations. In those cases, it's a nice, clean approach.

New Blazor component library

So here's something interesting that isn't getting a lot of attention: Microsoft is working on a component library for Blazor. Technically, these are wrappers around Microsoft's existing FluentUI Web Components and are built on FAST. You can fork the repository and browse to the examples app for a test page:

This is early, but I'd recommend taking a look—while it comes with the Blazor name, these are technically Razor components. This means you use them in other ASP.NET Core web apps, such as Razor Pages and MVC.

Microsoft customers have been asking for an in-house, free component library for a while—this will fill the need. While Microsoft will eventually introduce this as yet another tool at your disposal, they'll need to be careful here: the .NET community has a rich community of open-source and third-party component libraries (both free and paid), and they'll need to avoid the perception they're trying to replace these options. (To be abundantly clear, they definitely are not.)

.NET 6 Preview 4 has arrived

Just minutes into Build, Microsoft announced the official release of .NET 6 Preview 4. We've teased a few features in the last month or so, but it's nice to see the official news. Richard Lander wrote up the blog post. As a reminder, .NET 6 will be an LTS release.

.NET Hot Reload is a big .NET 6 feature (as is improving the developer inner loop in general). I've written about how you can use it by running dotnet watch with ASP.NET Core web apps (that is, Blazor, Razor Pages, and MVC). With Preview 4, you can also use it with other project types like WPF, Windows Forms, WinUI, console apps and "other frameworks that are running on top of the CoreCLR runtime." It's now integrated with the Visual Studio debugger as well—to do this, you need to download VS 2019 16.11 Preview 1.

In Lander's post, we also see much of what we've discussed previously: check out the official details on System.Text.Json improvements, LINQ enhancements, FileStream performance improvements on Windows, and new DateOnly and TimeOnly structs.

What about ASP.NET Core? ASP.NET Core is bringing it in this release—there's Minimal APIs, async streaming, HTTP logging middleware, improved SPA templates, Blazor error boundaries, and ... drum roll ... Blazor WebAssembly ahead-of-time (AOT) compilation! You can also start building .NET MAUI client-side apps with Blazor. Speaking of MAUI, there's a separate post outlining its Preview 4 updates. If you're using Entity Framework, make sure to check out that team's Preview 4 post to see all the wonderful perf improvements.

Preview 4 is a big one. Even with a little under six months to go, we'll only have a few previews to go until the focus turns to bug fixes. .NET 6 is coming along nicely.

Visual Studio updates

Last week, Microsoft also released Visual Studio 2019 v16.10 and v16.11 Preview 1.

With 16.10, we're seeing some more Git workflow improvements. The initial improvements to Git workflow in Visual Studio 2019 were a little rough, if we're being honest. It's nice to see the Visual Studio team listening to customer feedback and making it better. You can also now remove unused references—a long-adored ReSharper feature. In other news, there's improvements to Docker container tooling, IntelliSense completion improvements, Test Explorer improvements, and more. If F# is your jam, Phillip Carter announced some tooling updates for 16.10.

Also, if you're developing Azure Functions with the isolated worker in .NET 5, Azure Functions PM Anthony Chu has an update for you:

With 16.11 Preview 1, the big news is supporting hot reload in Visual Studio. We're also seeing .NET MAUI support.

On the topic of IDEs,  JetBrains released its roadmaps for ReSharper 2021.2 and Rider 2021.2.

Rethinking System.Console in .NET 7

With .NET 7—yes, .NET 7!—Microsoft is taking a look at redesigning System.Console.

As Adam Sitnik describes it, the initial design was driven by Windows OS capabilities and APIs. With .NET going cross-platform, it introduced a number of issues since there wasn't a good way to map Windows concepts to Unix. You're encouraged to follow the discussion and provide feedback.

We've seen a lot of community innovation in this space. For example, Patrik Svensson's Spectre.Console library shows us that the developer console experience can be productive and beautiful. This isn't lost and I'm interested to see how this work evolves.  

🌎 Last week in the .NET world

Welcome to Build week, where announcements are everywhere.

🔥 The Top 3

• Microsoft Build 2021 came and went—Amanda Silver and Scott Guthrie welcome you, and Microsoft provides the Build 2021 Book of News.
• Richard Lander announces .NET 6 Preview 4, Dan Roth announces ASP.NET Core updates, Shay Rojansky does the same for EF Core, and David Ortinau announces .NET MAUI Preview 4.
• Khalid Abuhakmeh announces the roadmap for ReSharper 2021.2 and also for Rider 2021.2.

📢 Announcements

• Microsoft releases Visual Studio 2019 v16.10 and v16.11 Preview 1, and Phillip Carter announces F# and F# tools updates.
• Dmitry Lyalin introduces the .NET Hot Reload experience for editing code at runtime.
• The Windows Package Manager goes 1.0, and Kayla Cinnamon releases Windows Terminal Preview 1.9.
• Troy Hunt announces that Have I Been Pwned is part of the .NET Foundation and a partnership with the FBI.
• Sam Basu announces Telerik UI for MAUI.

📅 Community and events

• David Ramel writes about the Visual Studio 2022 roadmap.
• The .NET Docs Show talks to Christos Matskas about Microsoft Identity.
• Wolfgang Hennerbichler writes about how GitHub is adopting OpenTelemetry.
• Because of Build, no community standups.

🌎 Web development

• The Code Maze blog uses Serilog with ASP.NET Core.
• Cody Merritt Anhorn uses Blazor with SignalR.
• Matthew Groves compares SQL and NoSQL in ASP.NET.
• Jeremy Likness writes about 10 Blazor features you might not know about.
• Jay Krishna Reddy writes about using OData in .NET 5.
• Mark Downie disables FLoC in ASP.NET.
• Joydip Kanjilal implements nanoservices in ASP.NET Core.
• Adam Storr calls a REST API with HttpClient in .NET 5.0.
• David McCarter processes data with microservices.

🥅 The .NET platform

• Patrick Smacchia migrates Delegate.BeginInvoke Calls to .NET Core, .NET 5 and .NET 6.
• Maarten Balliauw runs a .NET application as a service on Linux with Systemd.
• Steve Gordon uses DateOnly and TimeOnly in .NET 6.
• David Ramel provides updates on Project Reunion.
• Khalid Abuhakmeh explains the difference between HTML and URL Encode in .NET.
• Paula Fahmy begins a series on async C#.
• Jonathan Allen builds a source generator in C#.

⛅ The cloud

• Daniel Krzyczkowski uses Auth0 Actions with Azure Functions.
• Aaron Powell works with the Azure Static Web Apps CLI.

🔧 Tools

• Andrew Lock stops Visual Studio from creating launchsettings.json.
• Steve Smith disables logging loading symbols in VS Code.

📱 Xamarin

• Mark Allibone uses the OIDC client in Xamarin Forms to refresh an access token.
• Sam Basu provides his weekly MAUI update.

🎤 Podcasts

• The .NET Rocks podcast talks to Scott Hunter about Build 2021 announcements.
• The Adventures in .NET podcast talks to Chris Sainty about Blazor.
• The Azure DevOps Podcast talks to David Ortinau about MAUI.
• The Coding Blocks Podcast talks through some fun APIs.
• The 6-Figure Developer podcast talks about .NET Data with Jeremy Likness.

🎥 Videos

• Azure Friday provides an update on Azure Cosmos DB.
• The On .NET Show talks about clustering in Orleans and also C# exception filters.
• One Dev Question asks: who at Microsoft is using WinUI?
• The Xamarin Show improves accessibility with the Xamarin Community Toolkit.

Happy Monday! I hope you're all doing well.

Here's what's going on this week:

• The big thing: Previewing the big week ahead
• The little things: SecureString meeting its demise, the .NET Coding Pack, web dev news
• Last week in the .NET world

The big thing: Previewing the big week ahead

This week will be a big one: we've got Microsoft Build—probably the last virtual one—which kicks off on Tuesday. In what is surely not coincidental timing, .NET 6 Preview 4 should also be released. (And if that isn't enough, The .NET Stacks turns 1 next Monday. Please, no gifts.)

While Build doesn't carry the same developer excitement as it has in the past, in my opinion—the frenetic pace of .NET keeps us busy throughout the year, and, to me, Build has shifted toward a marketing event. Still, it'll be nice to watch some sessions and see where things are going. You can check out the sessions on the Build website.  I'll be keeping an eye on a .NET 6 deep dive, microservices with Dapr, and an Ask the Experts panel with many Microsoft .NET folks.

Next week, we'll also see the release of .NET 6 Preview 4 (finally!). While we'll pore over some of it next week when its formally communicated, the "what's new" GitHub issue really filled up this week and has some exciting updates.

New LINQ APIs

.NET 6 Preview 4 will include quite a few new LINQ APIs.

Index and Range updates

LINQ will now see Enumerable support for Index and Range parameters. The Enumerable.ElementAt method will accept indices from the end of the enumerable, like this:

Enumerable.Range(1, 10).ElementAt(^4); // returns 7

Also, an Enumerable.Take overload will accept Range parameters, which allows you to slice enumerable sequences easily.

MaxBy and MinBy

The new MaxBy and MinBy methods allow you to use a key selector to find a maximum or minimum method, like this (the example here is taken from the issue):

var people = new (string Name, int Age)[] { ("Tom", 20), ("Dick", 30), ("Harry", 40) };
people.MaxBy(person => person.Age); // ("Harry", 40)

Chunk

A new Chunk method allows you to chunk elements into a fixed size, like this (again, taken from the issue):

IEnumerable<int[]> chunks = Enumerable.Range(0, 10).Chunk(size: 3); // { {0,1,2}, {3,4,5}, {6,7,8}, {9} }

New DateOnly and TimeOnly structs

We talked about this in a past issue, but we'll see some new DateOnly and TimeOnly structs that add to DateTime support and do not deprecate what already exists. They'll be in the System namespace, as the others are. For use cases, think of DateOnly for business days and birthdays and TimeOnly for things like recurring meetings and weekly business hours.

Writing DOMs with System.Text.Json

So, this is fun: Preview 4 will bring us the ability to use a writable DOM feature with System.Text.Json. There's quite a few use cases here. A big one is when you want to modify a subset of a large tree efficiently. For example, you'll be able to navigate to a subsection of a large JSON tree and perform operations from that subsection.

There's a lot more with Preview 4. Check out the GitHub issue for the full details. We'll cover more next week.

The little things: SecureString meeting its demise, the .NET Coding Pack, general web dev news

The SecureString API seems great, it really does. It means well. It allows you to flag text as confidential and provide an extra layer of security. The main driver is to avoid using secrets as plain text in a process's memory. However, this doesn't translate to the OS, even on Windows. Except for .NET Framework, array contents are passed around unencrypted. It does have a shorter lifetime, so there's that—but it isn't that secure. It's easy to screw up and hard to get right.

The .NET team has been trying to phase out SecureString for awhile in favor of a more flexible ShroudedBuffer<T> type. This issue comment has all the juicy details of the latest updates.

This week, Scott Hanselman wrote about the .NET Coding Pack for Visual Studio Code. The pack includes an installation of VS Code, the .NET SDK (and adding it to the PATH), and a .NET extension. With the .NET Coding Pack, beginners will be able to work with .NET Interactive notebooks to quickly get started.

While we mostly talk about .NET around here, I think it's important to reach outside our bubble and keep up with web trends. I came across two interesting developments last week.

Google has decided to no longer give Accelerated Mobile Pages (AMP) preferential treatment in its search results (and they are even removing the icon from the results page). Whatever the reason—its controversy, lack of adoption, or Google's anti-trust pressure—it's a welcome step for an independent web. (Now, if only they'd bring back Google Reader.)

In other news, StackBlitz—in cooperation with Google Chrome and Vercel—has launched WebContainers, a way to run Node.js natively in your browser.  Simply put, it's providing an online IDE. Thanks to the strides WebAssembly has made in the past few years, it's paved a way for a WASM operating system.

Under the covers, it includes a virtualized network stack that maps to the browser's ServiceWorker API, which enables offline support. It provides a leg up over something like Codespaces or various REPL solutions, which typically need a server. I take exception with StackBlitz saying those solutions "provide a worse experience than your local machine in nearly every way" ... but if you do any JavaScript work, this is an exciting development (especially when dealing with JS's notoriously cumbersome tooling and setup demands).

🌎 Last week in the .NET world

🔥 The Top 3

• Jeremy Likness works with Azure Cosmos DB, EF Core, and Blazor Server.
• Matthew MacDonald asks: will Canvas rendering replace the DOM?
• Eve Turzillo organizes and modifies existing HTTP and HTTPS requests with Fiddler.

📢 Announcements

• Tara Overfield discusses the .NET Framework Cumulative Update for May.
• The Azure SDK team recaps the May release.
• Khalid Abuhakmeh writes about dotMemory support for Linux process dumps.

📅 Community and events

• Microsoft Build kicks off Tuesday. David Ramel previews Build 2021, and Richard Hay links to some digital swag. Also, the Visual Studio team previews their Build sessions.
• The .NET Foundation Outreach Committee announces a new proposal process.
• The .NET Docs Show talks to Steve Gordon about ElasticSearch.NET.
• A busy week with community standups: ASP.NET talks about accessibility, Entity Framework builds modern apps with GraphQL, and .NET Tooling discusses container tools.

🌎 Web development

• Tomasz Pęczek receives JSON Objects Stream (NDJSON) in ASP.NET Core MVC.
• Paul DeVito continues writing about building an event-driven .NET app.
• Anoop Kumar Sharma writes about cookie authentication in ASP.NET Core.
• StackBlitz introduces WebContainers, which provide the ability to run Node.js natively in your browser.
• Adam Storr defines HttpClient test requests by using a bundle.
• Davide Bellone exposes a .NET assembly version from API endpoint routing.
• Kirtesh Shah introduces ASP.NET Core Razor Pages.
• Damien Bowden secures OAuth bearer tokens from multiple identity providers in ASP.NET Core.
• Matthew Jones uses custom user message extension methods in C# and MVC.

🥅 The .NET platform

• Konrad Kokosa asks: why should you care about .NET GC?
• Khalid Abuhakmeh works with .NET console host lifetime events.
• Richard Lander writes about profile-guided optimization (PGO) in .NET 6.
• Nick Randolph writes about the future of Windows development.

⛅ The cloud

• Muhammed Saleem creates business workflows with Azure Logic Apps.
• Abhijit Jana explains how to get started with Azure quickly.
• Daniel Krzyczkowski continues his series on Azure Identity.
• John Reilly uses Azurite and Table Storage in a dev container.

📔 Languages

• Georg Dangl updates the Azure App Service on Linux for Docker with C# webhooks.
• Rick Strahl finds a gotcha with the C# null ? propagator when doing async/await.
• Munib Butt uses Azure Blob Storage in C#.
• Akash Mair writes about data exploration in F#.

🔧 Tools

• Abhijit Jana uses GitHub Actions from Visual Studio.
• Maarten Balliauw writes about the Rider NuGet Credential Provider for JetBrains Space private repos.
• Charles Flatt recaps the git commit/checkout process.

🏗 Design, testing, and best practices

• Dennis Martinez writes about 5 ways to speed up your end-to-end tests.
• Niels Swimberghe bypasses ReCaptcha's in Selenium UI tests.
• Scott Brady writes about authenticated encryption in .NET with AES-GCM.
• Derek Comartin talks about testing your domain when event sourcing.
• Christian Heilmann says you can't automate accessibility testing.

🎤 Podcasts

• Scott Hanselman talks to Rey Bango about developers and security.
• The Azure DevOps Podcast talks to Jeremy Likness about working with data in .NET.
• The .NET Core Show talks about dotnet new3 With Sayed Hashimi.
• The 6-Figure Developer podcast talks to Rich Lander about .NET 6 Preview.

🎥 Videos

• Learn Live continues learning about Git.
• The Let's Learn .NET series talks about building accessible apps.

Happy Monday! I hope you have a good week. Here's what we have this week:

• The big thing: Checking in on C# 10
• The little things: Azure Static Web Apps goes GA, JetBrains .NET days, .NET 6 FileStream improvements, JSON schema validation
• Last week in the .NET world

The big thing: Checking in on C# 10

Last week, Ken Bonny wrote a post highlighting some new C# 10 features. Of course, it's still a little early, and not all of these changes might make it in. But if language designer Mads Torgersen talks about them publicly, there's a good probability they will.

Ever since Microsoft rolled out records with C# 9, the community has been asking for record struct types. With the C# 9 release of records, the record type is a reference type that enforces value-like behaviors. With C# 10, the team is rolling out a record struct variant that makes the underlying type a value type. So, with a record struct, values will be copied over instead of by reference. Also, on the topic of records, you'll be able to add operators to them.

Apart from this, Ken recaps what else is (probably) coming:

• Flagging properties of classes, structs, records, or record structs as required
• A new field keyword that can eliminate backing fields
• Enabling a single file to enable namespace imports
• Improvements with lambda attributes and lambda signature inference

There's a lot more with Ken's post, with some good code examples. Make sure to check it out to see what's coming with C# 10.

The little things: Azure Static Web Apps goes GA, JetBrains .NET days, .NET 6 FileStream improvements, JSON schema validation

This week, Azure Static Web Apps became generally available (and to answer everyone's #1 question, yes, apex domains are supported now). I've written about it exhaustively with my Blast Off with Blazor blog series. The gist is this: you integrate your front-end (with various JavaScript frameworks or the Blazor component library) with a backend powered by Azure Functions.

This week, I recapped my favorite things about Azure Static Web Apps—some I knew previously and some I learned about this week. I'm most impressed with the local development story. When using an Azure Static Web Apps CLI, you can leverage a static site server, a proxy to your API endpoints, and a mock authentication and authorization server.

Azure Static Web Apps is now shipping with a Standard tier. For 9 USD/month, you can take advantage of a 99.95% SLA and a "bring your own Functions" model. I find the latter to be most valuable, especially when you want to leverage other Azure Functions triggers (by default, you can only use HTTP triggers with Azure Static Web Apps).

JetBrains hosted their .NET Days conference this week (online, of course). JetBrains always hosts first-class community events, and this was no different. You can check out all the sessions on YouTube.

On Day 1, folks talked about C# source generators, debugging .NET apps, writing high-performance code, Azure CosmosDB and React, gRPC in .NET, GraphQL and Blazor, and using .NET and Dapper.

On Day 2, we learned about the 10 best C# features, F#, legacy refactoring, using null and void in .NET, async and await best practices, debugging with JetBrains Rider, and containerizing with Kubernetes.

I'm getting a little antsy about the release of .NET 6 Preview 4. Since Preview 3 was shipped five weeks ago, and Microsoft aims for a new preview release every month or so, we'll see Preview 4 very soon. It'll be jam-packed with updates for minimal APIs, AOT support, and more.

We'll also see improvements to FileStream. The .NET team is rewriting the library, focusing on Windows (as the Unix implementation, built 20 years later, was already fast). With these changes, the team notes that when used with async I/O, it now never performs blocking work.

"Dave, shut up and show us the benchmarks!" OK, fine:

Look at those allocations! In the example above, reading a 1 MB file is 2.5x faster, and writing is 5.5x faster.

When it comes to serialization with .NET, you've got a few options: mostly, the tried-and-true Newtonsoft.Json (which just surpassed a billion NuGet downloads) and the native System.Text.Json library. Unfortunately, with System.Text.Json, there's no easy way to perform JSON schema validation, and schema validation is a paid feature with Newtonsoft.Json. (There are also quite a few third-party options for schema validation as well.)

This week, Matthew Adams wrote a wonderful post on achieving schema validation with System.Text.Json. He used code generation to create .NET types that represent the structure of the schema (with strongly typed accessors for properties, array/list elements, and so on).

🌎 Last week in the .NET world

This week, we learn more about Azure Static Web Apps, GitHub Actions, modular monoliths, and more.

🔥 The Top 3

• Derek Comartin recaps using Problem Details in ASP.NET Core Web API.
• Steve Gordon introduces GitHub Actions for .NET developers and writes about string manipulation in C#.
• Jon P. Smith continues his series on evolving modular monoliths.

📢 Announcements

• Microsoft announces the GA release of Azure Static Web Apps.
• Auth0 introduces Auth0 Actions.
• Microsoft announces the May updates for the .NET Framework.

📅 Community and events

• Thomas Claudius Huber introduces a new MVVM library.
• InfoQ talks to Jeremy Likness about EF Core.
• David Ramel writes about Mercury, a "modern Visual Basic."
• For community standups: Languages & Runtime talks about source generation, and Machine Learning differentiates between a data scientist and a data engineer.
• The .NET Docs Show discusses mobile accessibility.

🌎 Web development

• Adam Storr tests HttpClient.
• Muhammed Saleem integrates Azure Cosmos DB with ASP.NET Core Web API.
• David Grace creates a tic-tac-toe game in Blazor.
• Damien Bowden presents and verifies verifiable credentials in ASP.NET Core using decentralized identities and MATTR.
• Burak Guzel writes a primer on HTTP headers.
• Jason Beres compares Blazor to React.
• Calvin Allen works on real-time updates with Postgres and SignalR.

🥅 The .NET platform

• Tomasz Pęczek streams JSON Objects (NDJSON) with HttpClient.
• Paul DeVito builds an event-driven .NET application.
• Kristoffer Strube uses the PriorityQueue in .NET 6.
• Ken Bonny introduces C# 10.

⛅ The cloud

• Daniel Krzyczkowski continues writing about Azure Identity.
• John Reilly creates a pipeline with the Azure DevOps API.
• Mark Heath runs Durable Functions locally with Azurite.
• Dave Brock recaps his favorite things about Azure Static Web Apps.
• Aaron Powell uses Okta with Azure Static Web Apps.

📔 Languages

• Jeff Fritz writes about C# project structure.
• Sasha Mathews offers quick tips to improve C# performance.
• Matthew Adams works on C# serialization with JsonSchema and System.Text.Json.
• Kirtesh Shah writes about C# pattern matching.
• Khalid Abuhakmeh solves for the next DayOfWeek from DateTime.
• Josef Ottosson transforms C# objects to a flat string dictionary.
• Matthew Jones uses C# named arguments to handle complex tests.
• Brian Lagunas walks through async yield return in C#.

🔧 Tools

• David Ramel recaps free testing tools for Visual Studio 2019.
• Abhijit Jana reminds us that Visual Studio can add using directives automatically on paste.
• Aaron Stannard writes about integrating Akka.NET with ASP.NET Core and SignalR.
• Patrick Smacchia writes about the impacts of 64-bit Visual Studio 2022.
• Steve Smith fetches an upstream branch in GitHub.

🎤 Podcasts

• The Productive C# podcast talks about global usings in C# 10.
• The Coding Blocks podcast talks about making money with code.
• The 6-Figure Developer podcast discusses Orleans with Reuben Bond.
• The .NET Rocks podcast discusses Visual Studio 2022.
• The Azure DevOps podcast talks about customizing build agents.

🎥 Videos

• Azure Enablement plans for cloud adoption.
• The On .NET Show talks about supporting VB.NET in .NET 5 and C# ranges.
• Visual Studio Toolbox talks about Project Reunion.

Happy Monday! I hope you have a good week. Here's what we have this week:

• Is reflection still valuable?
• IdentityServer templates shipping with .NET 6
• Last week in the .NET world

Is reflection still valuable?

Last Monday, Marc Gravell asked: is the era of reflection-heavy C# libraries at an end? As C# source generators get more popular, developers might be wondering if it might someday replace the idea of reflection (for the unfamiliar, reflection is a way of discovering types at runtime).

Today, unless we're library authors, a lot of reflection is provided to us without us having to care:

This provides a pretty reasonable experience for the consumer; their code just works, and - sure, the library does a lot of work behind the scenes, but the library authors usually invest a decent amount of time into trying to minimize that so you aren’t paying the reflection costs every time.

As the industry has evolved, we've seen how reflection impacts modern applications. For example, we see increased demands on parallel code (async/await), AOT platforms, runtime error discovery, and more. If you're thinking of the cloud, runtime performance matters (especially if you're paying for serverless and execution times).

Marc states:

Imagine you could take your reflection-based analysis code, and inject it way earlier - in the build pipe, so when your library consumer is building their code ...  you get given the compiler’s view of the code ... and at that point you had the chance to add your own code ... and have our additional code included in the build ... This solves most of the problems we’ve discussed.

This doesn't mean reflection doesn't have its use cases, and it's so pervasive in the .NET ecosystem it isn't going anywhere anytime soon. Source generators are great for resolving performance headaches with certain reflection use cases like with GetTypes(). Should we go all-in on source generators, though? Is it worth moving code into a user's app and build processes over developers enjoying the separation?

Here's another consideration: is reflection just getting a bad rap? It can be slow for sure, but the .NET team has noted that performance is improving, and there's a prototype they're working on making 10x faster.

It'll be interesting to see how far the .NET platform pushes on source generators over improving reflection performance. I'm guessing we'll see a little in Column A and a little in Column B. Everything is a tradeoff. Still, it's promising to see source generators shake up decades of thinking reflection is the only way to inspect types dynamically.

IdentityServer templates shipping with .NET 6

Last December, IdentityServer introduced a licensing model (and we talked about it back in issue #20). You'll need to buy a license if your organization makes more than 1M USD/year (I know I have a global audience but believe me, you don't want me converting currency).

This week, Barry Dorrans announced that .NET 6 will continue to ship these templates (using the new RPL-licensed version). I personally applaud Microsoft's decision to continue to support IdentityServer, which is getting pushback from the blog's comments and a super-spicy GitHub issue. A lot of the pushback comes from folks accusing IdentityServer of a "bait and switch"—as if profiting off free open-source software for a decade wasn't enough—and that Microsoft should build it themselves.

As Microsoft has said a bunch of times, and bears repeating:

As stated we are not authentication experts, we have no expertise in writing or maintaining an authentication server. We have a team at Microsoft dedicated to that, and they produce AAD. The .NET team will not be writing production ready authentication servers, both because of the cost in that and because in doing so it's likely we'll cannibalize users from existing open source projects, something the community was very vocal in wanting us not to do when the initial discussions around IdentityServer inclusion was started.

🌎 Last week in the .NET world

We have a lot of great community posts this week.

🔥 The Top 4

• Marc Gravell asks: is the era of reflection-heavy C# libraries at an end?
• Thomas Ardal adds CAPTCHA on form posts with ASP.NET Core.
• Charlin Agramonte wires up a clearable time picker.
• Christopher Gill announces README NuGet package support.

📅 Community and events

• The .NET Foundation provides its March/April update.
• JetBrains .NET Days Online is happening this week.
• The .NET Docs Show talks to Greg Cannon about using .NET to build an e-ink dashboard for home automation.
• In community standups: ASP.NET talks about minimal APIs, Entity Framework discusses triggers, and Xamarin talks single-project architecture.

🕸 Web development

• Michael Shpilt writes about ASP.NET server problems and solutions.
• Khalid Abuhakmeh introduces Razor introduces Razor.
• Chinedu Imoh introduces JSON Web Tokens.
• Kristján Oddsson writes how GitHub uses Web Components.
• The Code Maze blog uses the ProblemDetails class in ASP.NET Core Web API.
• Damien Bowden creates an OIDC credential issuer with Mattr and ASP.NET Core.
• Jan Tattermusch talks about grpc-dotnet.

🥅 The .NET platform

• The Packt blog writes about upgrading existing .NET Apps to .NET 5.
• Maarten Balliauw builds a supply chain attack with .NET, NuGet, DNS, source generators, and more.

⛅ The cloud

• AWS announces the end of support for AWS SDK for .NET version 2 (v2).
• Lily Ma writes about Azure Event Grid, Event Hubs, and Service Bus Library Improvements.
• Daniel Krzyczkowski continues writing about Azure Identity.
• Abhijit Jana gets started with the Azure Web PubSub Service, then creates a messaging app using Azure Web PubSub Service and C#.

📔 Languages

• Ian Russell uses alternate ways of creating single-case discriminated unions in F#.
• Peter Vogel writes about value objects in C# 9.
• Patrick Smacchia writes about covariance and contravariance in C#.
• Anthony Giretti makes C# synchronous delegates asynchronous.
• Andrew Lock creates a simple moving average calculator.

🔧 Tools

• Abhijit Jana writes about Visual Studio going 64-bit.
• Ali Ok writes about Kubernetes configuration patterns.
• Anthony Giretti generates an installation command for VS Code installed extensions, and also writes about Thunder Client, a way for you to work with APIs right in VS Code.

📱 Xamarin

• Sam Basu provides his weekly MAUI update.
• Craig Dunn creates dual-screen apps.

🏗 Design, testing, and best practices

• Derek Comartin unpacks the “event” term.
• Pieter Humphrey writes about the value of serverless data APIs.
• Jon P. Smith writes about evolving modular monoliths.

🎤 Podcasts

• On the Software Engineering Podcast, Daniel Roth talks about Blazor.
• Serverless Chats talks about multi-cloud.
• The Azure Podcast talks to David Giard about Azure Media Services.

🎥 Videos

• Azure Friday talks about the Azure Resource Mover.
• The Xamarin Show builds accessible mobile apps.
• The Visual Studio Toolbox talks about EF Core.
• The DevOps Lab talks about cloud security.
• The On .NET Show talks about tuple pattern matching C#, uses Azure managed identities, and adds machine learning to .NET apps with ML.NET.

Last May, Microsoft stepped into the already busy static web app market with its Azure Static Web Apps offering. (Yes, you could—and still can!—accomplish this through Azure Storage and Azure CDN, but it's a lot of manual setup and maintenance.)  

With Azure Static Web Apps, you integrate your front-end—with JavaScript frameworks like Angular, React, Svelte, and Vue or C#'s Blazor component library—with a backend powered by Azure Functions. You can even deploy with static site frameworks like Hugo, Jekyll, and Gatsby.

Why do you want everything under one umbrella? It offers the following benefits:

• GitHub and Azure DevOps integration, where changes in your repo trigger build and deployments
• Your content is globally distributed
• Azure Static Web Apps works with APIs from a reverse-proxy model, meaning you don't have to deal with CORS configuration headaches
• Automated staging versions are generated whenever you open a pull request

I've played with Azure Static Web Apps for the last six months with my Blast Off with Blazor blog series. Azure Static Web Apps have evolved quite a bit, and Microsoft just ditched the preview label (like, hours ago). Microsoft doesn't typically recommend public preview bits for production-scale workloads, so this is big news: it's ready, and it scales, and ships with a Standard (non-free) tier with enterprise capabilities like bringing your own Azure Functions and a 99.95% SLA.

You can read a lot of posts and docs that'll introduce you to Azure Static Web Apps. (Can I suggest mine?) In this post, though, I'll take a different perspective: here are 5 of my favorite things.

Deployment environments

Let's say you have a trigger that is based on changes to your main branch. When you create a pull request against that branch, your changes are also deployed to a temporary non-production environment.

Here's how it looked for me:

You can push new updates to this environment as long as the PR is still open. This is useful when previewing changes, sending updates out to your team for approval and review, and so on. Once changes are merged into your branch, it disappears.

NOTE! Currently, staged environments are accessible by a public URL, so to quote Elmer Fudd: "Be vewy, vewy careful."

Authentication and authorization support

Out of the "free" box (if you don't want to open your wallet for the Standard plan), Azure Static Web Apps supports authorization with Azure AD, GitHub, and Twitter. Based on the provider, you send users invites from the Azure Portal (which assigns them to specific roles), and in a staticwebapp.config.json file, they are granted access to routes.

You can streamline access through /.auth/login/{provider}, and that URL is consistent all the way to production. In addition, you can set up redirect rules to authorize a provider and even block other ones:

{
  "route": "/login",
  "redirect": "/.auth/login/github"
}

{
  "route": "/.auth/login/twitter",
  "statusCode": "404"
}

With that in place, you can reference client authentication data from a direct-access endpoint with /.auth/me.

If you're on the Standard paid plan, you can also set up custom authentication—with this approach, you can authenticate with any provider that supports OIDC.

CLI support

It's great to clickety-click in the Azure Portal (yes, that's the technical term), but that doesn't scale. You'll need to automate your deployments eventually. To do this, you can use the Azure CLI's az staticwebapp commands.

Once you have an app in your repository (either GitHub or Azure DevOps), execute az login, login with your credentials, then create your Azure Static Web Apps instance with something like this:

az staticwebapp create \
    -n my-static-web-app \
    -g my-static-web-app-rg \
    -s https://github.com/daveabrock/my-static-web-app \
    -l eastus2 \
    -b main \
    --token <LOL_nice_try>

Of course, the CLI is not a one-trick pony. If you check out the docs, you can also work with app settings, manage the environment, manage users, and more.

You can also download the official Azure Static Web Apps CLI from npm or Yarn. This will supercharge your local development experience. Speaking of local development...

Local development isn't an afterthought

The thing about the cloud is ... well, it works great in the cloud. The local experience is often an afterthought. It's hard to predict how our apps work in the cloud without targeting our specific cloud resources. You can use the Azure Static Web Apps CLI to do a lot of heavy lifting for you.

The CLI provides a static site server, a proxy to your API endpoints, a mock authentication and authorization server, and more. This chart, borrowed from the docs, illustrates it better than I ever could (so I'll just steal borrow it):

You can run swa start to start your app, and even call some other API with the --api flag—this API doesn't even need to be part of your Azure Static Web Apps resource! So, that's nice. But really, I want to focus on the star of this show: the authorization and authentication emulator, which simulates the Azure security flow.

When a user logs in locally, you define a mocked identity profile. Earlier, we talked about GitHub authorization. In this case, when browsing to /.auth/login/github, you'll see a page that lets you define a profile.

You can define client principal values here, use /.auth/me to get a client principal, and then execute the /.auth/logout endpoint to clear the principal and log out the mock user. I have absolutely no interest in mocking Azure authentication myself. This is a wonderful feature.

Apex domain support

This is a little tongue-in-cheek, but I can't help but get excited about root/APEX domain support—this gives you the ability to configure your site at blastoffwithblazor.com and not just www.blastoffwithblazor.com. Previously, you had to hack your way around Cloudflare using Burke Holland's blog post to do this, but no more! (Sorry, Burke—no, your Google Analytics is not playing games on you.)

This support was missing throughout the previews because of the impacts, but you can now do this through simple TXT record validation. After you enter your domain in the Azure Portal, configure a TXT record with your provider to prove ownership, then create an ALIAS record back in the Azure Portal.

Wrap up

In this post, I recapped my favorite things about Azure Static Web Apps: deployment environments, CLI support, the local development environment, authentication and authorization support, and apex domain support.

How has your experience been? Let me know in the comments!

Jekyll was great. So why did I switch?

Over the last 18 months, I've gone from being a typical "I should blog more" developer to pushing out content consistently twice a week. It's been quite the experience: like working with code over time, some pieces I'm proud of, some make me cringe, but I'm happy with my progress.

I love serving the community, but it can be time-consuming (like most community members, most of my work is on my own time on top of a busy family life and a day job). I easily spend a few hours a month (if not more) on maintaining various aspects of my Jekyll site. As I'm trying to serve the developer community in different ways, I've lost the passion for maintaining my site myself. These days, I want to open a browser and write. (I did try various Jekyll CMS's, but none were a good fit.) I want to be as productive as I can and am OK with not having complete control over every part of my site. It's your textbook IaaS vs. PaaS vs SaaS argument: do you want convenience or control?

That's not to say the time spent maintaining my site was wasted. I enjoyed learning about static site generators and the Ruby ecosystem. It's just not something I want to invest time in anymore. I'm also very happy with Ghost as a CMS. From a pure writing and publishing perspective, I think it's a better and more productive experience for me.

After taking a fresh look at my site, it was a good opportunity to find a decent commenting system.

Scrapping Disqus

Some time ago, I scrapped comments altogether on my site. Comments are a great way to engage (and learn, improve, and exchange ideas with my readers) but I couldn't handle Disqus, the most popular (and free) commenting system. It's bloated, has a sketchy tracking history, and a suspect advertising engine. In terms of performance, I shouldn't have to read articles on lazy-loading Disqus comments just to make its performance acceptable. So, I scrapped Disqus until I could find a better alternative.

I've decided to use Commento, a commenting system that is focused on privacy and performance. I see a lot of folks I trust are using it, and I like what I see so far. It does come with a cost, but it's minimal (and is covered my generous GitHub sponsors, Niels Swimberghe and Thomas Ardal). I'm more than happy to support good software.

I hope you enjoy the new site. If you don't (or you do), please let me know in the comments. Thanks for reading!

Happy Monday! Here’s what we’re talking about this week:

• One big thing: Microsoft announces Azure Web PubSub
• The little thing: Logging middleware coming, new try-convert release, and EF perf improvements
• Last week in the .NET world

Microsoft announces Azure Web PubSub

Last week, Microsoft rolled out a public preview of Azure Web PubSub, a managed service for building real-time web applications using web sockets. According to Microsoft, Azure Web PubSub enables you to use WebSockets and the publish-subscribe pattern to build real-time web applications easily. This service helps you manage a lot of concurrent WebSocket connections for data-intensive apps. In these scenarios, implementing at scale is a challenge. It lowers the barrier to entry: all you need is a WebSocket client and an HTTP client. Think about simple messaging patterns with a lot of connections. What’s nice here is that you can use any addressable endpoint with Azure Web PubSub. Azure Web PubSub integrates with Azure Functions natively, with the capability to build serverless apps with WebSockets and C#, Python, Java, or JavaScript. You use anything that can connect from a web socket, even desktop apps.

Here’s what’s on our minds: how is this different than the SignalR service? While both services are internally built from similar tech, the most significant difference is that there’s no client or protocol requirement with Azure Web PubSub. You can bring your WebSocket library if you wish. And also, unlike SignalR, you’re just working with WebSockets here—you won’t see automatic reconnect scenarios, long polling, and whatnot.

What does this mean for SignalR? Nothing. As a matter of fact, according to David Fowler, here’s when you’d want to stick with SignalR:

• You’re a .NET-specialized dev shop and have SignalR client libraries and expertise
• You need fallbacks other than WebSockets, like long polling or server-sent events
• The existing SignalR client platforms work for you
• You don’t want to manage a custom protocol and need more complex patterns (and want SignalR to manage it for you)
• You don’t want to manage the reconnect logic yourself

Anthony Chu sums it up pretty well when he says:

Personally, I would use SignalR unless you need to support clients that don’t have a supported SignalR library. You could write the code connect/reconnect/messaging code yourself but SignalR does it all for you with a nice API.

Speaking of WebSockets, WebSocket compression is coming to .NET 6 thanks to a community contribution from Ivan Zlatanov. It’s an opt-in feature, and it looks like Blazor won’t be using it for now. Security problems can arise when server messages contain payloads from users and, as a result, shouldn’t be compressed.

The little things: Logging middleware coming, new try-convert release, and EF perf improvements

As we discussed last week, .NET 6 Preview 4 will be a big release with lightweight APIs and AOT on the list (if not more). For Preview 5, ASP.NET Core will be introducing logging middleware. Logging request and response information isn’t the most fun, so middleware will do a lot of the heavy lifting for you (and you can extend it if needed). By default, the logging middleware won’t log response bodies, but that should be a configuration detail. This is a problem every ASP.NET developer has to deal with, so it’s nice to see it being generalized.

A new try-convert release was shipped last week. This release includes enhancements for VB.NET Windows Forms conversions. The new, snazzy .NET Upgrade Assistant relies on this try-convert tool, which means VB.NET WinForms support has arrived with the Upgrade Assistant. That’s all I’m going to say about that because the more you talk about VB.NET, the more someone calls you an expert.

I missed this last week, but the Entity Framework team announced the results from new TechEmpower benchmarks. It looks like EF Core 6 is 33% faster than EF Core 5, and EF Core is also almost 94% of the Dapper performance.

🌎 Last week in the .NET world

🔥 The Top 3

• Brian Lagunas walks through yield return in C#.
• Giorgi Dalakishvili introduces GraphQLinq, a LINQ-to-GraphQL library.
• Microsoft announces Azure Web PubSub.

📢 Announcements

• Microsoft announces that .NET Framework 4.5.2, 4.6, 4.6.1 will reach End of Support on April 26, 2022.
• Asia Rudenko introduces ReSharper 2021.1.2 and Rider 2021.1.2.
• Uno writes about Uno Platform 3.7.
• Alexandra Kolesova writes how ReSharper and Rider 2021.2 will require .NET Framework 4.7.2 or newer installed on Windows.

📅 Community and events

• The Azure SDK wants your feedback on the next phase of the Azure SDK.
• Alberto Gimeno writes how GitHub uses feature flags.
• Microsoft Build registration is now open.
• Maarten Balliauw comments on ReSharper and Visual Studio 2022 64-bit.
• For community standups: ASP.NET talks about SPA updates and Machine Learning talks about .NET Notebooks and .NET Interactive.
• The .NET Docs Show talks to Irina Scurtu about versioning APIs.

🌎 Web development

• Jeremy Likness works on multi-tenancy with EF Core in Blazor Server apps.
• Damien Bowden secures an ASP.NET Core app and Web API using Windows auth.
• Claudio Bernasconi works on Blazor form handling and input validation .
• Marinko Spasojevic works on Blazor material form creation with file uploads and dialogs.
• Daniel Jiminez Garcia uses Blazor WebAssembly, SignalR and C# 9 to create Full-stack Real-time Applications.
• Cody Merritt Anhorn works with the IntersectionObserver API in Blazor.
• Khalid Abuhakmeh accesses background services from ASP.NET Core.
• Waqas Anwar supports multiple versions of ASP.NET Core Web API.

🥅 The .NET platform

• Nick Randolph explains why he doesn’t want or need WinUI for UWP.
• Matthew MacDonald writes about a lack of Linux support for .NET 6 desktop apps.
• Sam Walpole warns against deferred execution in LINQ.
• Maarten Balliauw investigates a crashing devenv.exe.

⛅ The cloud

• Matias Quaranta writes about improving your Azure Cosmos DB .NET SDK initialization.
• Carlos Souza compares deploying containers in Azure and AWS.
• Jessica Deen refactors for microservices using Linux and Windows containers.
• Jamie Maguire works on aspect-based sentiment analysis with Azure Cognitive Services Text Analytics.

📔 Languages

• Damir Arh discusses nullable reference type best practices.
• Jonathan Allen walks through .NET 6 LINQ improvements.
• Khalid Abuhakmeh reads and writes Excel spreadsheets in C#.
• Tom Deseyn completes his series on C# 9 features.

🔧 Tools

• Billy Griffin writes about GitHub Desktop updates.
• Davide Bellone works with FluentValidation.
• Dave Brock makes microservices fun again with Dapr.
• Andrew Lock tries out the open-source eCommerce platform nopCommerce using Docker.
• Rory Primrose revisits NSubstitute and FluentAssertions.
• Peter Vogel writes about strategy and tools for APIs.

📱 Xamarin

• Leomaris Reyes replicates a Book Worm UI in Xamarin Forms.
• Sam Basu provides his weekly MAUI update.
• Matt Lacey writes about Uno Platform and Xamarin.Forms.

🏗 Design, testing, and best practices

• Derek Comartin talks about aggregate design.
• The NDepend blog writes about a Clean Architecture refactoring case study.

🎤 Podcasts

• The .NET Core Podcast talks about dependency injection with Steve Collins.
• The Productive C# Podcast discusses the new DateOnly and TimeOnly structs in C#.
• The Azure DevOps Podcast discusses Blazor architecture.
• The Azure Podcast talks about keeping up with Azure.
• The Adventures in .NET podcast talks about interactive C# with VS Code Notebooks.
• The .NET Rocks show talks with Simon Cropp about Verify.
• The Coding Blocks podcast talks about writing great APIs.

🎥 Videos

• The On .NET Show talks about authentication for serverless apps, init-only setters, default interface methods in C#, and GitHub Codespaces.
• Azure Enablement talks about cloud financial considerations.

Happy Monday! Here’s what we’re talking about this week:

• One big thing: Visual Studio 2022 to be 64-bit
• The little thing: API updates coming to Preview 4, memory dump tooling, dotnet monitor updates
• Last week in the .NET world

One big thing: Visual Studio 2022 to be 64-bit

Last week, I provided a tooling update. Figuring the next major updates would occur around Build, it was a good time to get up to speed. I pushed the newsletter, started my workday, then an hour later, Amanda Silver wrote a post about Visual Studio 2022. Oops.

The biggest news: Visual Studio 2022 will be 64-bit and is no longer chained to limited memory (4 gigs or so) in the main devenv.exe process. If you look at Silver’s post, she has a video of a 64-bit Visual Studio app working easily with 1600 projects and 300k files. Finally.

With interest dating back in 2011, the Visual Studio team responded in 2016, saying that “at this time we don’t believe the returns merit the investment and resultant complexity.” Times have changed—hardware capabilities have improved, and VS is no longer the only .NET IDE option—and it’s now worth it.

For example, if you look at the issue in the Developer Community, a few comments echo what Microsoft has heard for a few years now:

This year my company(size 15k+) started to provide RAIDER to employees and plans to cancel our Enterprise VS subscriptions as VS is highly unproductive because of memory limitations of 32 bit application.

Lately I’m mainly using Rider. It does about 80% of what VS does, but it does that 80% without worrying about running out of ram.

To be clear, as David Ramel notes, Visual Studio has been available in a 64-bit edition to create 64-bit apps on 64-bit machines, but the application itself has previously been a 32-bit app. JetBrains cheekily welcomed Visual Studio to the 64-bit club, but this also means ReSharper will have more room to breathe. When the time comes, you’ll need to grab 64-bit versions of your favorite extensions as well.

Of course, 64-bit support isn’t the only thing coming to Visual Studio 2022. VS 2022 promises a better UI interface, enhanced diagnostics and debugging, productivity updates, improved code search, and more. The first preview will ship this summer, with UI refinements and accessibility improvements. In the meantime, you can check out the most requested features from the community.

The little things: API updates coming to Preview 4, async analyzers, dotnet monitor updates

A couple weeks ago, we talked about the FeatherHttp project, a lightweight, scalable way of writing APIs without the typical overhead that comes with .NET APIs today.

Here’s what I said about it:

Fowler says the repo has three key goals: to be built on the same primitives on .NET Core, to be optimized to build HTTP APIs quickly, and having the ability to take advantage of existing .NET Core middleware and frameworks. According to a GitHub comment, the solution uses 90% of ASP.NET Core and changes the Startup pattern to be more lightweight.

That functionality will start rolling out in .NET 6 Preview 4 in a few weeks. (Along with AOT support, Preview 4 promises to be a satisfying update.)

David Fowler tweeted about it and the discussion was spicy.

I’m personally excited to give this a spin. If it isn’t your jam, it doesn’t have to be—it isn’t a breaking change, and you can always use your current solution. But as APIs evolve with microservices, much of the core logic is done outside of the endpoints anyway, so you may find you don’t need the complexity and overhead with writing APIs in MVC.

Mark Downie and his team have been doing some great work with managed memory dump analyzers. If you think that’s too low-level, reconsider—when logging and local debugging fail you (or issues aren’t reproducible easily), memory dump analysis can be your friend. It isn’t always easy to work with memory dumps, though. To help folks new to dump debugging, Microsoft has developed a new .NET Diagnostics Analyzer tool to quickly identify or rule out issues.

A great use case is finding async anti-patterns, a common cause of thread starvation, which only may become prevelant when you hit high production workloads. Check out the blog post to see how it can detect some “sync-over-async” issues.

In passing, we’ve talked about the dotnet monitor tool. It allows you to access diagnostics information with a dotnet process. It’s no longer experimental: it’s now a supported tool in the .NET ecosystem. Sourabh Shirhatti wrote about that and recent updates.

Lastly, a nice tip from Khalid Abuhakmeh:

🌎 Last week in the .NET world

🔥 The Top 3

• Kristoffer Strube works with DynamicComponent in Blazor.
• Leomaris Reyes writes about getting started with Xamarin Forms.
• Konrad Kokosa has a quiz to check your level of knowledge about .NET memory management.

📢 Announcements

• Amanda Silver rolls out Visual Studio 2022.
• Sourabh Shirhatti writes about what’s new in dotnet monitor.
• Mark Downie announces memory dump analyzers that detect async antipatterns.

📅 Community and events

• GitHub rolls out a new Mars 2020 Helicopter Mission badge.
• Maarten Balliauw announces new .NET tutorials from JetBrains.
• Microsoft is putting on a free live stream event on Friday called “Let’s Learn .NET”.
• Shahed Chowdhuri is launching a new “Azure, Simplified” video series.
• For weekly standups: ASP.NET talks about .NET 6 ASP.NET Core updates and Entity Framework shows off how to contribute.
• The .NET Docs Show optimizes Linux containers with Robert Rozas.

🌎 Web development

• Matthew Jones continues building a Tetris app in Blazor.
• Jeff Fritz introduces his KlipTok project.
• Jon Hilton asks: will .NET 6 fix Blazor Prerendering?
• Claudio Bernasconi builds a dashboard in Blazor.
• David Grace explains why the ASP.NET Core FromBody can return null.
• Sardar Mudassar Ali tests an ASP.NET Core 5 Web API service with Swagger.
• Thomas Claudius Huber works with local storage and session storage in Blazor.
• Muhammad Rehan Saeed writes about CSS best practices.
• Damien Bowden secures multiple Auth0 APIs in ASP.NET Core using OAuth bearer tokens.
• Marinko Spasojevic uses MudBlazor to work with a product detail page.
• Khalid Abuhakmeh adds Svelte to ASP.NET Core projects.

🥅 The .NET platform

• Andrew Lock fixes a build warning when building projects with end-of-life .NET frameworks.
• David Ramel writes about the top feature requests for Visual Studio 2022.
• Scott Hanselman converts his 13-year-old .NET BabySmash app to a self-contained .NET 5 app with the .NET Upgrade Assistant.
• Richard Lander talks about the crossgen2 tool.

⛅ The cloud

• Daniel Krzyczkowski starts a series on Azure Identity.
• Imar Spaanjaars deploys to the Azure App Service.
• The AWS Blog writes about the AWS SDK for .NET’s runtime pipeline and client configuration, and also introduces the AWS Toolkit for Visual Studio support for AWS SSO and Assume Role with MFA.
• GitHub Actions rolls out protections to fight cryptomining.

📔 Languages

• Brian Lagunas compares Task and ValueTask.
• Tom Deseyn works with init accessors and records in C# 9.

🔧 Tools

• Steve Smith adds ImgBot to his GitHub repository.
• Paul DeVito works on .NET Core integration tests using a SQL Server database in Docker.
• Jay Krishna Reddy uses CQRS with MediatR in .NET 5.
• ErikEJ uses Entity Framework Core with Azure Managed Identity, App Service/Functions, and Azure SQL DB.
• David Hayden works with Orchard Core, .NET 5, and C# 9.
• Auth0 introduces a new CLI.
• Khalid Abuhakmeh fixes .NET ICU build issues in GitHub Actions.

📱 Xamarin

• Rakeshkumar Desai gets started with .NET MAUI.
• Almir Vuk talks to David Ortinau about .NET MAUI.

🏗 Design, testing, and best practices

• Derek Comartin asks: do microservices require containers, Docker, or Kubernetes?
• Scott Hannen writes about the Partial/Optional Object Population (POOP) anti-pattern. (Finally, a blog post suitable for both me and my 3-year-old.)
• Adam Storr creates and manipulates mock anonymous data for unit tests.

🎤 Podcasts

• The .NET Core Podcast talks about libvlcsharp and .NET with Martin Finkel.
• The Complete Developer podcast talks about quickly learning new technologies.
• The Productive C# Podcast discusses how to become a fluent C# developer with Codingame.
• The 6-Figure Developer podcast talks about Blazor with Carl Franklin.
• The .NET Rocks podcast talks to Gerald Versluis about going from Xamarin to MAUI.
• The Merge Conflict podcast answers your questions.
• Serverless Chats discusses how serverless fits in to the cyclical nature of the industry.

🎥 Videos

• Visual Studio Toolbox gets started with Jupyter notebooks in VS Code.
• The On .NET Show talks about build automation with NUKE, works through top-level statements in C# 9, and uses the static directive in C#.

In theory, though, I’ve seen monoliths open for abuse. After some time, the monolith becomes complicated, changes are filled with unintended side effects, and it becomes difficult to manage. Even simple changes require full deployments of the entire application, and testing is a nightmare. In these cases, you may want to consider a microservice architecture. With anything else, you need to understand what you’re getting yourself into.

Instead, you’re signing up to manage a bunch of smaller applications with a lot to consider: how can I monitor and observe my services? How can I make them robust and resilient? How can I work with async communication, like messaging and event-driven patterns? When I do need to be synchronous, how can I handle that? How can I scale? Did I mention it has to be cloud-native through containerization and a container orchestrator like Kubernetes?

Three months after your stakeholders ask you to build a shopping cart, you’re looking at an app filled with complex dependencies, cobbled-together SDKs, and complicated configuration setups. You now spend your days futzing with YAML files—and believe me, some days it’s a word dangerously close to futzing—and you can’t help but wonder: wasn’t I supposed to be developing things?

Dapr, or Distributed Application Runtime, is here to help. Production-ready since February and sponsored by Microsoft, it manages distributed applications for you through a “building blocks” mechanism. These pluggable components manage the various layers of complexity for you:

• State management
• Invoking services
• Bindings
• Observability
• Secrets
• Actors

In these cases, you tell Dapr which “component to use”—like Redis or SQL Server, for instance—and Dapr will handle the rest for you through a singular SDK or API. While you may be worried about a single layer of abstraction, this provides a lot of value over other options like Istio or Orleans: one SDK to manage all your complexity.

Dapr uses a sidecar pattern. From your services, you can connect to Dapr from HTTP or gRPC. Here’s what it looks like (this graphic was stolen from the Dapr Docs):

Even more, you can enjoy the benefits from your local machine. You can configure Dapr to run the Dapr CLI.

You may think you need to Dapr-ize your entire application if you want to leverage it—this is not true. If you feel you could benefit by doing pub-sub over HTTP, use that piece and leave the rest of the application alone. This isn’t an all-or-nothing approach.

Before we proceed with one of my favorite Dapr use cases, let’s answer a common question.

Is this a new Service Mesh?

Is this a new Service Mesh? Thankfully, no.

If you’re unfamiliar, a service mesh is an infrastructure layer that can provide capabilities like load-balancing, telemetry, and service-to-service communication. In many ways, you might think abstracting these capabilities away from the services themselves is a step forward. In reality, though, I hate them so much. Adding another hop in your service to a complicated mesh that requires a talented I&O team to administer, coupled with a terrible developer experience? No, thanks. When I see these solutions, I wonder: does anyone think about the people who build applications?

While these meshes use a sidecar pattern like Dapr, it is not a dedicated network infrastructure layer but a distributed application runtime. While a service mesh enables things from the network perspective, Dapr has that and more: application-level capabilities like actors that can encapsulate logic and data, complex state management, bindings, and more.

This isn’t a binary decision, of course—you could add service meshes with Dapr to isolate networking concerns away from application concerns.

Get your feet wet with simplified pub-sub

Because Azure Service Bus does not provide a great local development experience—and not without some discussion on making it better—it isn’t uncommon to see developers use RabbitMQ locally and in development environments but Azure Service Bus in production. As with the Dapr for .NET Developers ebook, you can provide an abstraction layer, but swapping between the two is a lot of work.

Here’s an example, using the Dapr .NET SDK, for publishing an event to a concert topic:

var band = new Band
{
  Id = 1,
  Name = "The Eagles, man"
};

var daprClient = new DaprClientBuilder().Build();

await daprClient.PublishEventAsync<OrderData>("pubsub", "concert", band);

The Dapr SDK allows you to decorate your ActionResult methods with a Topic attribute. For example, here’s how a CreateBand signature would look:

[Topic("pubsub", "concert")]
[HttpPost("/bands")]
public async Task<ActionResult> CreateBand(BandModel band)

In ASP.NET Core, you’ll need to let the middleware know you’re working with Dapr in the ConfigureServices and Configure methods:

public void ConfigureServices(IServiceCollection services)
{
    // other stuff omitted
    services.AddControllers().AddDapr();
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // other stuff omitted
    app.UseCloudEvents();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapSubscribeHandler();
    });
}

If I was using RabbitMQ with Dapr, I would include something like this in my configuration:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pubsub-rq
spec:
  type: pubsub.rabbitmq
  version: v1
  metadata:
  - name: host
    value: "amqp://localhost:5672"
  - name: durable
    value: true
  - name: deletedwhenunused
    value: true

If I wanted to swap it out with Azure Service Bus, I could update my configuration. (Each provider has various configuration levels, as you can see.)

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: <NAME>
  namespace: <NAMESPACE>
spec:
  type: pubsub.azure.servicebus
  version: v1
  metadata:
  - name: connectionString
    value: <myconnectionstring> 
  - name: timeoutInSec
    value: 75 
  - name: maxDeliveryCount
    value: 3
  - name: lockDurationInSec
    value: 30

With the Dapr pub/sub model, a nice benefit is the capability to subscribe to a topic in a declarative fashion. In this example, I can define the Dapr component, the topic to subscribe to, the API to call, and which services have pub/sub capabilities.

apiVersion: dapr.io/v1alpha1
kind: Subscription
metadata:
  name: concert-subscription
spec:
  pubsubname: pubsub
  topic: concert
  route: /bands
scopes:
- ThisService
- ThatService
- TheOtherService

While a quick example—I plan a future dedicated post of Dapr pub-sub—you can see the benefits, especially when swapping dependencies. In the Dapr for .NET Developers ebook, Microsoft says they could remove 700 lines of code using Dapr to switch between RabbitMQ and Azure Service Bus.

Conclusion

In this article, we introduced Dapr. We walked through the problems it solves, how it compares to a Service Mesh, and a simple scenario using pub-sub with RabbitMQ and Azure Service Bus. As I’m just beginning to get my feet wet, look for more posts on the topic soon!

References

• Dapr for .NET Developers (a good read and inspiration for the use case I provided, check it out)
• Dapr Docs

• One big thing: Catching up on your IDEs
• The little thing: More on the Upgrade Assistant, k8s in Microsoft Learn, bUnit news
• Last week in the .NET world

One big thing: Catching up on your IDEs

There’s been a lot of news lately on the IDE front. Whether you’re using Visual Studio or JetBrains Rider, there have been some big releases that are worth reviewing. (I’m focusing on IDEs here—I realize you can do .NET in VS Code, but that’s more of an editor, even if it can sometimes feel like an IDE with the right extensions.)

As for VS, last Wednesday, Microsoft released Visual Studio 2019 v16.10 Preview 2. From the .NET perspective (C++ is not part of the .NET family, so I don’t mention those), it includes many IntelliSense updates. You’ll now see completions for casts, indexers, and operators, the ability to automatically insert method call arguments when writing method calls, a UI for working with EditorConfig files, and a new way to visualize inheritance.

The release also contains new features for working with containers: you can run services defined from your Docker Compose files, and there’s also a new containers tooling window. You’ll also see some nice improvements with the Test Explorer. You can finally view console logs there, navigate to links from log files, and automatically create log files.

Finally, Visual Studio has pushed out updates to the Git experience. With v16.10, Visual Studio’s status bar now features an enhanced branch picker, a repository picker, and a sync button. You can also select a commit to open an embedded view of its details and the file changes in the Git Repository window without having to navigate to other windows (an excellent way to compare commits). You can learn about the Git changes in a devoted blog post. With the admission I haven’t checked it out in a while, I’ve found the Git experience not to be very feature-rich. I might have to check it out again.

What about Rider? Earlier this month, JetBrains wrote about the Rider 2021.1 release. If you work in ASP.NET MVC, Web APIs, or Razor Pages, Rider now features scaffolding for Areas, Controllers, Razor Pages, Views, and Identity. It also generates boilerplate code for EF CRUD operations. Rider now supports ASP.NET Core route templates with inspections to check HTTP syntax errors and quick-fixes to fix route parameter issues.

They’ve also made some improvements to support the latest C# features: there’s increased support for patterns and records, and Rider has a new set of inspections and quick-fixes with records themselves. If you’re into tuples, Rider now allows you to use them with its refactoring tooling. They’ve even started looking at C# 10 and have taught Rider to work with the new “Constant interpolation strings” feature.

You can check out the What’s New in Rider page for all the details on their latest release.

The little things: More on the Upgrade Assistant, k8s in Microsoft Learn, bUnit news

Last week, I talked about hot reload in .NET 6. A few of you were kind enough to let me know that you were having issues seeing the GIFs. If you were having problems, I apologize (you can look at the web version of the newsletter and see them in action). I was looking into hot reload for a piece for the Telerik developer blog that was published last week. Check it out to see how you can enable it, how it works, how it handles errors and its limitations.

While I’m already doing some shameless plugs, I also wrote a piece about the .NET Upgrade Assistant. We’ve mentioned it in passing, but it’s a global command-line tool that guides you through migrating your .NET Framework apps to .NET 5. It doesn’t do everything for you, as many APIs like System.Web isn’t available in .NET Core—but it goes a long way in doing the painful bits. It comes with an (optional) accessibility model, which allows you to customize upgrade steps without modifying the tool itself. For example, you can explicitly map NuGet packages to their replacements, add custom template files and add custom upgrade steps. To do this, you include an ExtensionManifest.json file.

When I migrated an MVC app, I thought about using it to delete the App_Start folder and its contents automatically. It isn’t supported (but is now tracked!) as right now, you can only find files. In cases like these, though, I would hope this would be done automatically. But if you’re migrating a bunch of projects and know how you want to port over some code, you can customize it yourself. It should save you quite a bit of time.

Kubernetes has now made its way to Microsoft Learn. Microsoft shipped a new module that walks you through application and package management using Helm. You can provision Kubernetes resources from the in-browser Azure Cloud Shell.

Did you think I’d write about Kubernetes and not leave you with a funny joke?

Congrats to Egil Hansen. bUnit, his popular Blazor testing library, is out of preview and has officially hit v1.0. You can check out the release notes for the latest release.

The API proposal for C# 10 interpolated strings is now officially approved. Check it out on GitHub.

🌎 Last week in the .NET world

🔥 The Top 4

• Andrew Lock views overwritten configuration values in ASP.NET Core.
• Jeremy Likness writes about an easier way to debounce in Blazor.
• Steve Smith tests exceptions with XUnit and Actions.
• Anthony Giretti uses fluent integration tests with EF Core and xUnit.

📢 Announcements

• Microsoft releases Windows Terminal Preview 1.8 and Visual Studio 2019 v16.10 Preview 2.
• The Azure SDK team provides its April update.

📅 Community and events

• Kevin Dockx updates his Marvin.JsonPatch library.
• The Azure Cosmos DB Conf starts on Tuesday.
• JetBrains is hosting .NET Days on May 11-12.
• In community standups: ASP.NET standup talks to Shaun Walker about Oqtane, .NET Tooling talks about .NET Interactive, and Machine Learning holds office hours.
• The .NET Docs Show talks to Rehan Saeed about NuGet packages.

🌎 Web development

• Ben Foster customizes authorization responses in .NET 5.0.
• Dave Brock writes about hot reload in .NET 6.
• Matthew Jones continues writing a Tetris game in Blazor.
• Khalid Abuhakmeh generates links to ASP.NET Core map endpoints, and also adds models to ASP.NET Core.
• David Ramel writes about the new Blazor WebView controls.
• Marinko Spasojevic works with tables in MudBlazor.
• Damien Bowden secures Blazor Web Assembly using cookies and Auth0.

🥅 The .NET platform

• Nick Randolph adds behaviors to a WinUI Uno Application.
• Jonathan Allen writes about .NET 6 async improvements.
• David Ramel writes about what’s new in .NET 6 Preview 3.
• Nick Randolph restyles controls in an Uno (Windows UI) application.
• Laurent Ellerbach writes about the story of .NET nanoFramework.

📔 Languages

• Jeff Fritz writes about C# nullability.
• Damir Arh makes code simpler with C# 9.
• Tom Deseyn writes about C# 9 new features for methods and functions.

🔧 Tools

• Dave Brock writes about the .NET Upgrade Assistant.
• Mark Downie debugs managed Linux core dumps with Visual Studio.
• Munib Butt uses NDepend in Visual Studio.
• Craig Morten starts a series on his AKS performance journey.
• Chandra Kudumula uses ML.NET to predict insurance rates.
• Pratik Nadagouda writes about using Visual Studio with Git.
• Gerard Gallant deploys C# web applications in Docker.
• Aaron Stannard builds headless Akka.NET services with IHostedService.
• Khalid Abuhakmeh writes about ReSharper & Rider improvements For Avalonia.
• Elie Bou Issa automates Azure DevOps with Logic Apps.

📱 Xamarin

• Sam Basu provides another MAUI update.
• Selva Ganapathy Kathiresan replicates a Facebook-like UI.

🏗 Design, testing, and best practices

• Grant Fritchey explains how microservices architecture changes database deployment.
• Derek Comartin organizes microservices.
• Over at Software Alchemy, scaffolding your clean DDD web app.
• Scott Hannen continues writing about his experiment with making integration tests easier to write.

🎤 Podcasts

• The Adventures in .NET podcast discusses the merits of CI/CD.
• The Coding After Work podcast catches up with Carl Franklin.
• The Working Code podcast discusses feature flags.
• The .NET Rocks podcast talks to Ian Cooper about TDD in 2021.
• The Changelog talks to Daniel Stenberg about managing curl..
• The Azure DevOps Podcast talks about Azure development.

🎥 Videos

• The On .NET Show secures apps with Microsoft Identity, and target-typed new expressions in C# 9.
• The ASP.NET Monsters deal with truncation with string and binary values.

Moving is just the worst.

You have to rent a truck, hope it’ll hold all your things, beg friends and family to help, and feel the pain for days after the move. And during the move, you tell yourself: “Someday, I’ll hire someone to take all this stress off my hands. Imagine what I could be doing instead of all this tedious work!” The next time you move, you hire a moving company, and it’s incredible. The movers handle all the heavy lifting while you focus on breaking in your new home.

This is the promise of the .NET Upgrade Assistant, a global command-line tool that helps you migrate your .NET Framework apps to .NET 5. If .NET Framework is the sturdy home that’s showing its age and getting harder to repair and .NET 5 is a modern, efficient home built with state-of-the-art materials, the .NET Upgrade Assistant is the moving company that makes your life easier.

Let’s be clear: the .NET Upgrade Assistant is not a magic wand. You’ll likely need to do some manual work as you migrate. However, the tool can do most of your heavy lifting and allow you to focus on what’s important.

What exactly does the .NET Upgrade Assistant do? In prerelease, it’s a guided tool that leads you through your migration.

It performs the following tasks:

• Adds analyzers that assist with upgrading
• Determines which projects to upgrade and in what order
• Updates your project file to the SDK format
• Re-targets your projects to .NET 5
• Updates NuGet package dependencies to versions compatible with .NET 5, and removes transitive dependencies present in packages.config
• Makes C# updates to replace .NET Framework patterns with their .NET 5 equivalents
• Where appropriate, adds common template files

The .NET Upgrade Assistant allows you to migrate from the following .NET Framework application types.

• Windows Forms
• WPF
• ASP.NET MVC apps
• Console apps
• Class libraries

We’re going to evaluate the .NET Upgrade Assistant by migrating a legacy ASP.NET MVC app, eShopLegacyMVCSolution, which runs .NET Framework 4.7.2. I’ve borrowed this from the repository for the Microsoft e-book, Modernize existing .NET applications with Azure cloud and Windows containers, by Cesar de la Torre. My daveabrock/UpgradeAssistantDemo repository contains both the legacy solution and my upgraded solution. As a bonus, you can review my commit history to see how the code changes after each step.

Before You Start

Before you start using the Upgrade Assistant, make sure you’re familiar with Microsoft’s porting documentation and understand the migration limitations, especially when deciding to migrate ASP.NET applications. Additionally, you can use the .NET Portability Analyzer tool to understand which dependencies support .NET 5. It’s like calling the moving company first to find out what they can and cannot move and how long it might take.

Before you install the .NET Upgrade Assistant, you must ensure you install the following:

• Visual Studio 2019 16.8 or later (Visual Studio is required because the tool uses MSBuild to work with project files)
• The .NET 5 SDK

The tool also depends on the try-convert tool to convert project files to the SDK style. You must have version 0.7.212201 or later to use the Upgrade Assistant.

From a terminal, run the following to install the .NET Upgrade Assistant. (It’s a global tool, so you can run the command anywhere.)

dotnet tool install -g try-convert

If you have try-convert installed but need to upgrade to a newer version, execute the following:

dotnet tool update -g try-convert

Install the .NET Upgrade Assistant

We’re now ready to install the .NET Upgrade Assistant. To do so, execute the following from a terminal:

dotnet tool install -g upgrade-assistant

After installing the .NET Upgrade Assistant, run it by navigating to the folder where your solution exists and entering the following command.

upgrade-assistant <MySolution.sln>

Use the Upgrade Assistant to Migrate to .NET 5

To get started, I’ll run the following command from my terminal. (The default command should work, but if needed, you can pass other flags like --verbose.)

upgrade-assistant eShopDotNet5MVC.sln

The tool executes and shows me the steps it will perform. For each step in the process, I can apply the next step in the process, skip it, see details, or configure logging. Most of the time, you’ll want to select Apply next step. To save some time, you can press Enter to do this.

When the tool starts, it places a log.txt file at the root of your project.

Back Up Project

The first step is to back up the project. The .NET Upgrade Assistant asks if you want to use a custom path for your backup or a default location. Once this completes, we’re ready to convert the project file.

Convert Project Files to SDK Style

.NET 5 projects use the SDK-style format. In this step, the Upgrade Assistant converts your project file to this SDK format using the try-convert tool. During this process, we see the tool is warning us that a few imports, like System.Web, might need manual intervention after migration.

Update TFM

Next, the .NET Upgrade Assistant will update the Target Framework Moniker (TFM) to .NET 5.0. In my case, the value changes from net472 to net5.0.

Update NuGet Packages

Once the Upgrade Assistant updates the TFM, it attempts to update the project’s NuGet packages. The tool uses an analyzer to detect which references to remove and which packages to upgrade with their .NET 5 versions. Then, the tool updates the packages.

Add Template Files

After the tool updates any NuGet packages, it adds any relevant template files. ASP.NET Core uses template files for configuration and startup. These typically include Program.cs, Startup.cs, appsettings.json, and appsettings.development.json.

Migrate Application Configuration Files

Now the tool is ready to migrate our application configuration files. The tool identifies what settings are supported, then migrates any configurable settings to my appSettings.json file. After that is complete, the tool migrates system.web.webPages.razor/pages/namespaces by updating _ViewImports.cshtml with an @addTagHelper reference to Microsoft.AspNetCore.Mvc.TagHelpers.

Update C# Source

Now, the .NET Upgrade Assistant upgrades C# code references to their .NET Core counterparts. You’ll see several steps listed in the terminal—not all apply. In those cases, they’ll be skipped over and flagged as [Complete].

In my case, the step first removes any using statements that reference .NET Framework namespaces, like System.Web. Then, it ensures my ActionResult calls come from the Microsoft.AspNetCore.Mvc namespace. Finally, the Upgrade Assistant  ensures that I don’t use HttpContext.Current, which ASP.NET Core doesn’t support.

The final step is to evaluate the next project. Since our solution only has one project, the tool exits.

Manually Fix Remaining Issues

As you head back to your project, you’ll see build errors. This is normal. This tool will automate a lot of the migration for you, but you’ll still need to tidy some things up. A majority of these issues involve how ASP.NET Core handles startup, configuration, and bundling.

• The Global.asax and Global.asax.cs files are no longer needed in ASP.NET Core, as the global application event model is replaced with ASP.NET Core’s dependency injection model, in Startup.cs.
• You won’t need the App_Start folder or any of the files in it (BundleConfig.cs, FilterConfig.cs, and RouteConfig.cs). Go ahead and delete it. Feels good, doesn’t it?
• After you do this, most of your remaining errors are related to the bundling of your static assets. ASP.NET Core works with several bundling solutions. Read the bundling documentation and choose what works best for your project.
• Finally, fix any issues that remain. Your mileage may vary, but my changes were minimal. For example, in my _Layout.cshtml file, I had to inject an IHttpContextAccessor to access the HttpContext.Session and I also needed to clean up some ActionResult responses.

Extending the .NET Upgrade Assistant

While the Upgrade Assistant fulfills most of your use cases, it has an optional accessibility model that allows you to customize upgrade steps without modifying the tool yourself. For example, you can explicitly map NuGet packages to their replacements, add custom template files, and add custom upgrade steps. To get started, you’ll include an ExtensionManifest.json file that defines where the tool finds the different extension items. You need a manifest, but all of the following elements are optional, so you can define only what you need.

{
  "ExtensionName": "My awesome extension",

  "PackageUpdater": {
    "PackageMapPath": "PackageMaps"
  },
  "TemplateInserter": {
    "TemplatePath": "Templates"
  },

  "ExtensionServiceProviders": [
    "MyAwesomeExtension"
  ]
}

When you run the Upgrade Assistant, you can pass an -e argument to pass the location of the manifest file, or define an UpgradeAssistantExtensionPaths environment variable. Check out the documentation for details.

Do you remember when we manually deleted the Global.asax and the contents of the App_Start folder? If we’re upgrading many projects, consider adding a custom upgrade step to delete these.

Learn More

As I mentioned, the .NET Upgrade Assistant is a promising and powerful tool—however, it’s in prerelease mode and is quickly evolving. Make sure to check out the tool’s GitHub repository to get up to speed and report any issues or suggestions. You can also review the tool’s roadmap.

Stay tuned for improvements.  For example, .NET 5 is a “Current” release—this means it’s supported for 3 months after .NET 6 officially ships (the support ends in February 2022). .NET 6, to be released this November, is a Long Term Support (LTS) release—meaning it’s supported for a minimum of 3 years.  As a result, you’ll soon see the ability to choose which release to target.

Conclusion

In this article, we toured the new .NET Upgrade Assistant and showed how to speed up your migration to .NET 5. Have you tried it? Leave a comment and let me know what you think.

• One big thing: .NET 6 Preview 3 is here, and so is hot reload
• The little thing: C# updates
• Last week in the .NET world

.NET 6 Preview 3 is here, and so is hot reload

On Thursday, Microsoft rolled out .NET 6 Preview 3. Richard Lander has the announcement covered. As he notes in the post, the release is “dedicated almost entirely to low-level performance features.” For example, we’ve got faster handling of structs as Dictionary values, faster interface checking and casting thanks to the use of pattern matching, and code generation improvements. The team resolved an issue where NuGet restore failed on Linux thanks to previous certificate issues. There were also updates to EF Core and ASP.NET Core.

Oh, and initial hot reload support is finally here.

Hot reload isn’t just for Blazor developers to enjoy—it’s built into the .NET 6 runtime. With Preview 3, you can use it by running dotnet watch in your terminal with ASP.NET Core web apps—Razor Pages, MVC, and Blazor (Server and WebAssembly). In future updates, you’ll enjoy Visual Studio support and use it with other project types like mobile, console apps, and client and mobile apps.

It’s been highly requested, and for a good reason—front-end frameworks and libraries based on interpreted languages like JS have enjoyed this for the last five years, and it’s a fantastic productivity booster. It’s easy to rag on Microsoft for taking this long—but they’ve had more significant problems during this time. Five years ago, Microsoft was preparing the roll out of the first version of .NET Core, and a component library like Blazor was just a thought, if at all. Now, the runtime is ready to address these issues (as it’s a main goal of .NET 6).

I tried out hot reload with Blazor Server this weekend (a blog post is coming). I’ll include some GIFs that show what it’s like.

Here’s basic editing of static text:

Here’s what happens when I update C# code:

In the following example, you’ll see here that it preserves state. When I change the currentCount value, the state of the component is maintained. I’ll need to refresh the page to see the new currentCount.

Here’s where I put it all together by dropping in components (with independent state) and editing some CSS for good measure.

However, not all code actions are supported. When this happens—like renaming a method—it will revert to current dotnet watch behavior by recompiling and refreshing your page with the latest bits.

If you have runtime errors, a banner displays at the top with the appropriate information. When you resolve your issues, the app will recompile and refresh.

On the subject of Blazor, Preview 3 ships with a BlazorWebView control. This allows WPF and Windows Forms developers to embed Blazor functionality into existing .NET 6 desktop apps.

The little thing: C# updates

Last week, Bill Wagner announced open-source C# standardization. In addition to the compiler work repo (in dotnet/roslyn) and the repo for C# language evolution (dotnet/csharplang), there is now a new repo (dotnet/csharpstandard) dedicated to documenting the standard for the latest C# language versions.

The new repo sits under the .NET Foundation, and as Wagner states:

Moving the standards work into the open, under the .NET Foundation, makes it easier for standardization work. Everything from language innovation and feature design through implementation and on to standardization now takes place in the open. It will be easier to ask questions among the language design team, the compiler implementers, and the standards committee. Even better, those conversations will be public … The end result will be a more accurate standard for the latest versions of C#.

If you’re having trouble distinguishing between dotnet/csharplang and dotnet/csharpstandard, you aren’t alone. Bill Wagner notes that there’s some overlap between the repos, and it’s a work in progress.

Speaking of C#, it’s nice to check out any language proposals from time-to-time, and file-scoped namespaces is making progress as a C# 10 proposal.

🌎 Last week in the .NET world

🔥 The Top 3

• Richard Lander announces .NET 6 Preview 3, and Dan Roth shows off the ASP.NET Core updates in .NET 6 Preview 3.
• The .NET Docs Show has a C# roundtable with C# gods Mads Torgersen, Bill Wagner, and Jon Skeet.
• The NuGet team addresses restore failures on Linux distributions using NSS or ca-certificates, and Nikolche Kolev writes about NuGet performance improvements.

📢 Announcements

• Microsoft announces a preview of their own OpenJDK build.
• Jorge Garcia Hirota announces GA client libraries for Azure Communication Services.
• Dapr v1.1.0 is now available.
• The AWS SDK for .NET version 1 has reached the end of support.
• Andrew Lock announces the second edition of his book, ASP.NET Core in Action.

📅 Community and events

• Bill Wagner announces open-source C# standardization.
• For community standups: Languages & Runtime discusses C# standardization, Entity Framework talks about Azure SQL, and ASP.NET discusses Microsoft Identity.

🌎 Web development

• Kevin W. Griffin asks: does SignalR guarantee message deliverability?
• Claudio Bernasconi works on static images in Blazor.
• Dave Brock works with DynamicComponent in Blazor.
• Niels Swimberghe creates ZIP files on HTTP request without intermediate files using the ASP.NET MVC framework.
• Matthew Jones continues building his Tetris app in Blazor.
• Damien Bowden creates verifiable credentials in ASP.NET Core for decentralized identities using Trinsic.
• Marinko Spasojevic creates a Blazor nav menu using Material UI.
• Sam Xu writes about attribute routing in ASP.NET Core OData 8.0 RC.
• Kristoffer Strube troubleshoots a 404 issue when deploying Blazor Web Assembly to GitHub Pages.

🥅 The .NET platform

• David Hayden installs .NET on Ubuntu.
• Nick Randolph gets started with the Uno platform.
• Peter Vogel writes about moving to desktop applications in .NET 5.
• Andrea Chiarelli writes about secrets management in .NET apps.
• Sergey Tihon configures dotnet watch with Microsoft.Identity.Web or custom IDistributedCache.
• Tom Deseyn writes about C# 9 pattern matching.