DEV Community: Dave Brock

Don't Do That, Do This: The .NET 6 Edition

Dave Brock — Wed, 08 Dec 2021 14:28:47 +0000

This post is my annual contribution to the 2021 C# Advent Calendar. Please check out all the great posts from our wonderful community!

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(justTheDate); // 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 e xtended 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.

.NET 6 Has Arrived: Here Are A Few of My Favorite Things

Dave Brock — Fri, 03 Dec 2021 12:59:58 +0000

This post was originally published on the Telerik Developer Blog.

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.

Use AzCopy to migrate files from AWS S3 to Azure Storage

Dave Brock — Sun, 21 Nov 2021 16:47:50 +0000

At the risk of upsetting Jeff Bezos, I recently moved a few million PDF files from Amazon S3 to Azure Storage (Blob Storage, in fact). I kept it simple and opted to use Microsoft's AzCopy tool. It's a command-line tool that allows you to copy blobs or files from or to an Azure Storage account. AzCopy also integrates with the Azure Storage Explorer client application, but using a UI wasn't ideal with the number of files I had.

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 from the AWS side. 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 to begin using AzCopy—and let me know what you think of it!

Exploring C# 10: Use Extended Property Patterns to Easily Access Nested Properties

Dave Brock — Thu, 18 Nov 2021 01:34:28 +0000

Welcome back to my series on new C# 10 features. So far we've talked about file-scoped namespaces and global using declarations. Today, we'll talk about extended property patterns in C# 10.

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",
    Suits = new List<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.

If you're interested in the design proposal, you can also find it here.

Let me know your thoughts below. Happy coding!

Exploring Fiddler Jam: What's New?

Dave Brock — Sat, 06 Nov 2021 15:00:42 +0000

This post was originally featured on the Telerik Developer Blog.

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 Securityfor 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.

Saying goodbye to The .NET Stacks

Dave Brock — Thu, 04 Nov 2021 12:42:14 +0000

I wanted to write a quick note to let everyone know that I will no longer be producing The .NET Stacks. This does not mean I'll be going away or leaving the wonderful .NET community—it just means I'll be producing content in other ways.

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.

The .NET Stacks #68: 🍿 What a week

Dave Brock — Tue, 26 Oct 2021 23:27:37 +0000

Happy ... Tuesday? It's been quite an interesting week. We have one thing to discuss, and then straight to the links.

.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

The .NET Stacks #67: 🆕 .NET 6 RC2 arrives

Dave Brock — Sun, 24 Oct 2021 16:39:29 +0000

Welcome to another week, full of top-notch product announcements and the proclamation of "View Source" as a crime. I too am a hacker, apparently.

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.

Exploring C# 10: Global Using Declarations

Dave Brock — Thu, 21 Oct 2021 03:18:57 +0000

Welcome back to my series on new C# 10 features. I kicked off this series by writing about file-scoped namespaces, a simple but powerful way to remove unnecessary verbosity from your C# code. This time, we're talking about a new feature that achieves similar goals: global using declarations.

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.

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.

The .NET Stacks #66: 🧀 Who moved my cheese?

Dave Brock — Mon, 18 Oct 2021 00:38:34 +0000

I know I'm a day or so late. Sorry, I was reading about Web 3.0 and still don't know what it is. Do you? After reading this, it made me want to cry, laugh, and then cry again. As if Dapr and Dapper isn't enough, now we have "dapps."

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.

The .NET Stacks #65: 💡 Is there hope for a modern C# model?

Dave Brock — Sun, 10 Oct 2021 16:33:00 +0000

Happy Monday to you all and happy October. I hope you have a good week. My goal: to develop a data model simpler than this one.

Here's what we have this week:

Exploring modern C#
Custom deployment layouts for Blazor WebAssembly apps
Last week in the .NET world

Exploring a modern subset of .NET's dominant language

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:

Kathleen Dollard

@kathleendollard

@dotnetstacks It seems you can have 2 of the 3: language evolution, backwards compat, one way to do things.

Would you give up the simplicity of var or the simplification possible with tuples for a single way to do things?

23:35 PM - 29 Sep 2021

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.

Exploring C# 10: Save Space with File-Scoped Namespaces

Dave Brock — Tue, 05 Oct 2021 03:35:27 +0000

.NET 6 and C# 10 hit general availability next month (in November 2021). Much like I did with C# 9 last year, I'd like to write about C# 10 over my next few posts. First, let's talk about a simple yet powerful capability: file-scoped namespace declarations.

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.

DEV Community: Dave Brock

Don't Do That, Do This: The .NET 6 Edition

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

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

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

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

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

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

Speaking of brackets ...

Wrapping up

.NET 6 Has Arrived: Here Are A Few of My Favorite Things

Hot Reload

Minimal APIs

Simplified HTTP logging

Blazor improvements

Error boundaries

Dynamic components

Preserving pre-rendered state

C# 10 updates

Use AzCopy to migrate files from AWS S3 to Azure Storage

Authorize AzCopy to access your Azure Storage account and Amazon S3

Copy an AWS bucket directory to Azure Storage

Resuming jobs

Performance optimization tips

Wrap up

Exploring C# 10: Use Extended Property Patterns to Easily Access Nested Properties

Exploring Fiddler Jam: What's New?

Video recordings

Better tracking for user events

Capture storage information

How do the Advanced Options work now?

Updated sharing options

More coming!

Saying goodbye to The .NET Stacks

The .NET Stacks #68: 🍿 What a week

.NET Open Source: Who does Microsoft want to be?

🌎 Last week in the .NET world

📢 Announcements

📅 Community and events

🌎 Web development

🥅 The .NET platform

📔 Languages

🔧 Tools

🏗 Design, testing, and best practices

🎤 Podcasts

🎥 Videos

The .NET Stacks #67: 🆕 .NET 6 RC2 arrives

Web updates with .NET 6 RC 2

New .NET 6 LINQ API: Chunk

🌎 Last week in the .NET world

📢 Announcements

📅 Community and events

🌎 Web development

🥅 The .NET platform

⛅ The cloud

🔧 Tools

🏗 Design, testing, and best practices

🎤 Podcasts and videos

Exploring C# 10: Global Using Declarations

Are some common namespaces globally available by default?

Can I incorporate global usings with project configuration?

Do I have to use these?

The .NET Stacks #66: 🧀 Who moved my cheese?

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

📢 Announcements

📅 Community and events

🌎 Web development

🥅 The .NET platform

⛅ The cloud

📔 Languages

🏗 Design, testing, and best practices

🎤 Podcasts and videos

The .NET Stacks #65: 💡 Is there hope for a modern C# model?

Exploring a modern subset of .NET's dominant language

Custom deployment layouts for Blazor Web Assembly apps

🌎 Last week in the .NET world

📢 Announcements

📅 Community and events