Forem: Shawn Wildermuth

Is it Time to Panic? Suddenly, Everyone Seems to Need a Job

Shawn Wildermuth — Tue, 15 Aug 2023 00:00:00 +0000

In my last blog post, I mentioned that I was pivoting to what I’m doing next. It feels a lot of people are going through an upheaval. Is it systemic?

To be clear, I have no idea what’s happening but it looks like a lot of organizations have taken the current landscape to trim their rolls. Of course, some of you might think AI is the culprit but I talked about that in one of my rants if you want to go flame me there ;)

Over the past month or so, I’ve watched as Pluralsight, LinkedIn, Plex, Microsoft and I am sure more that I haven’t noticed. Earlier in the year, the announcement from Facebook, Alphabet, Twitter and Microsoft already left some people worried.

A lot of these jobs seem to be more about developer relations. This seems like a pattern. Sure, startups like SourceGraph are hiring, but can they absorb the other layoffs? I don’t know.

Am I concerned? For my own future, sure. I’m 54 and ageism exists, but I have faith in my abilities. The real concern for me, is that Developer Advocates are being cut. There is a real movement towards Discord as documentation and developer relationships. I think this trend is newer than the pandemic.

The other side of the coin is that overall the unemployment rate is actually pretty low. For me, that meant I wasn’t looking at jobs outside of the tech companies. Sometimes I forget that most tech jobs aren’t in tech companies like Ford, Geico, and Wells Fargo. So, if you’re looking, don’t forget that tons of other companies have openings (in fact, reach out if you are a Vue developer that can work remote, I know of a job or two).

Lastly, I wanted to highlight a few people that I know are looking and that I think are genuinely great. Here are their LinkedIn links:

David Neal: https://www.linkedin.com/in/davidneal/
Joe Guadagno: https://www.linkedin.com/in/josephguadagno/
Ted Neward: https://www.linkedin.com/in/tedneward/
Lars Klint: https://www.linkedin.com/in/lklint/

I am not sure I’m looking for a job yet, but I’m still writing courses and working with clients for the time being. This fall may tell a different tale.

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

Where Have I Been?

Shawn Wildermuth — Mon, 31 Jul 2023 00:00:00 +0000

I went to my blog the other day and noticed my last story here was in February. I guess I got a little distracted. So, what have I been up to? Let’s talk about it.

Over the last couple of years, like many blogs, I’ve seen the readership dwindle. This doesn’t mean I think it’s time to abandon the blog. But with so many other things taking my time, I suspect I won’t be blogging quite as regularly as I have in the past. After 1730 blog posts, this blog has been really important to me. I’d never abandon it.

So, if I’m not blogging, what am I doing?

The Film

The most obvious answer to this is the film I’ve been working on since the beginning of Covid: Man Enough to Heal. The film post-production wrapped in May. Since then, I’ve submitted it to film festivals and engaged a sales agent to find distribution. I’m quite happy with the results and can’t wait to share here when it’s available to watch!

Pluralsight Courses

Since the beginning of the year, I’ve working full-time updating and creating new courses for Pluralsight. Right now, I’m in the middle of updating my long ASP.NET Core, End-to-End course for .NET 6 (and .NET 8 when it ships). The other courses I’ve released or updated this year include:

Coding Shorts

While blogging has waned, I’ve been focused on doing short videos I’m calling “Coding Shorts”. These videos are ten or so minutes long so I can teach one, discrete skill or technology. I’ve made 67 of these so far. Here’s one of my recent ones if you’re interested in getting a taste of them:

I’ve also authored a handful of “Rants” where I talk about the industry and my opinions about what is important. You can find all the videos at my channel:

https://shawnl.ink/yt

The Pivot

Lastly, I’ve been spending time thinking about what is next. Every once in a while (~10 years), I find the need to change the direction of my career. Teaching and training have been great, but I think I’m ready for another challenge. In the past, these pivots have been about what things I’ve focused on. Some of these include:

xBase development that pivoted to C++
C++ pivoted to COM and ActiveX
COM and ActiveX that pivoted to ASP.NET and C#
ASP.NET/C# pivoted to desktop development with WPF/XAML
WPF/XAML pivoted to Silverlight training
And lastly, Silverlight pivoted back to ASP.NET and .NET Core

But where do I go next? I have no idea. But I realize that this is likely my last pivot. This means I’m looking to do something that excites me and that I think is important to do. But who knows what that is. I’m scaling back my training and doing more client work, but I’d love to find some clients that are doing important things. If you think you’re one of those companies, feel free to reach out on my work site:

https://shawn.wildermuth.com

Last Thing…

In case you don’t know, I release a newsletter every week with the articles that I find useful — both software related and other tech (e.g. Space, Science). If you want to subscribe, feel free to visit:

https://shawnl.ink/newsletter

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

Minimal API Discovery Tool

Shawn Wildermuth — Wed, 22 Feb 2023 00:00:00 +0000

I’ve been posting and making videos about ideas I’ve had for discovering Minimal APIs instead of mapping them all in Program.cs for a while. I’ve finally codified it into an experimental nuget package. Let’s talk about how it works.

I also made a Coding Short video that covers this same topic, if you’d rather watch than read:

How It Works

The package can be installed via the dotnet tool:

dotnet add package WilderMinds.MinimalApiDiscovery

Once it is installed, you can use an interface called IApi to implement classes that can register Minimal APIs. The IApi interface looks like this:

/// <summary>
/// An interface for Identifying and registering APIs
/// </summary>
public interface IApi
{
  /// <summary>
  /// This is automatically called by the library to add your APIs
  /// </summary>
  /// <param name="app">The WebApplication object to register the API </param>
  void Register(WebApplication app);
}

Essentially, you can implement classes that get passed the WebApplication object to map your API calls:

public class StateApi : IApi
{
  public void Register(WebApplication app)
  {
    app.MapGet("/api/states", (StateCollection states) =>
    {
      return states;
    });
  }
}

This would allow you to register a number of related API calls. I think one class per API is too restrictive. When used in .NET 7 and later, you could make a class per group:

  public void Register(WebApplication app)
  {
    var group = app.MapGroup("/api/films");

    group.MapGet("", async (BechdelRepository repo) =>
    {
      return Results.Ok(await repo.GetAll());
    })
      .Produces(200);

    group.MapGet("{id:regex(tt[0-9]*)}", 
      async (BechdelRepository repo, string id) =>
    {
      Console.WriteLine(id);
      var film = await repo.GetOne(id);
      if (film is null) return Results.NotFound("Couldn't find Film");
      return Results.Ok(film);
    })
      .Produces(200);

    group.MapGet("{year:int}", (BechdelRepository repo, 
        int year, 
        bool? passed = false) =>
        {
          var results = await repo.GetByYear(year, passed);
          if (results.Count() == 0)
          {
            return Results.NoContent();
          }

          return Results.Ok(results);
        })
      .Produces(200);

    group.MapPost("", (Film model) =>
    {
      return Results.Created($"/api/films/{model.IMDBId}", model);
    })
      .Produces(201);

  }

Because of lambdas missing some features (e.g. default values), you can always move the lambdas to just static methods:

public void Register(WebApplication app)
{
  var grp = app.MapGroup("/api/customers");
  grp.MapGet("", GetCustomers);
  grp.MapGet("", GetCustomer);
  grp.MapPost("{id:int}", SaveCustomer);
  grp.MapPut("{id:int}", UpdateCustomer);
  grp.MapDelete("{id:int}", DeleteCustomer);
}

static async Task<IResult> GetCustomers(CustomerRepository repo)
{
  return Results.Ok(await repo.GetCustomers());
}

//...

The reason for the suggestion of using static methods (instance methods would work too) is that you do not want these methods to rely on state. You might think that constructor service injection would be a good idea:

public class CustomerApi : IApi
{
  private CustomerRepository _repo;

  // MinimalApiDiscovery will log a warning because
  // the repo will become a singleton and lifetime 
  // will be tied to the implementation methods.
  // Better to use method injection in this case.
  public CustomerApi(CustomerRepository repo)
  {
    _repo = repo;
  }

// ...

This doesn’t work well as the call to Register happens once at startup and since this class is sharing that state, the injected service becomes a singleton for the lifetime of the server. The library will log a warning if you do this to help you avoid it. Because of that I suggest that you use static methods instead to prevent this from accidently happening.

NOTE: I considered using static interfaces, but that requires that the instance is still a non-static class. It would also limit this library to use in .NET 7/C# 11 - which I didn’t want to do. It works in .NET 6 and above.

When you’ve created these classes, you can simple make two calls in startup to register all IApi classes:

using UsingMinimalApiDiscovery.Data;
using WilderMinds.MinimalApiDiscovery;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddTransient<CustomerRepository>();
builder.Services.AddTransient<StateCollection>();

// Add all IApi classes to the Service Collection
builder.Services.AddApis();

var app = builder.Build();

// Call Register on all IApi classes
app.MapApis();

app.Run();

The idea here is to use reflection to find all IApi classes and add them to the service collection. Then the call to MapApis() will get all IApi from the service collection and call Register.

How it works

The call to AddApis simply uses reflection to find all classes that implement IApi and add them to the service collection:

  var apis = assembly.GetTypes()
    .Where(t => t.IsAssignableTo(typeof(IApi)) && 
                t.IsClass && 
                !t.IsAbstract)
    .ToArray();

  // Add them all to the Service Collection
  foreach (var api in apis)
  {
    // ...
    coll.Add(new ServiceDescriptor(typeof(IApi), api, lifetime));
  }

Once they’re all registered, the call to MapApis is pretty simple:

var apis = app.Services.GetServices<IApi>();

foreach (var api in apis)
{
  if (api is null) throw new InvalidProgramException("Apis not found");

  api.Register(app);
}

Futures

While I’m happy with this use of Reflection since it is only a ‘startup’ time cost, I have it on my list to look at using a Source Generator instead.

If you have experience with Source Generators and want to give it a shot, feel free to do a pull request at https://github.com/wilder-minds/minimalapidiscovery.

I’m also considering removing the AddApis and just have the MapApis call just reflect to find all the IApis and call register since we don’t actually need them in the Service Collection.

You can see the complete source and example here:

https://github.com/wilder-minds/minimalapidiscovery

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

Digging Into Nullable Reference Types in C#

Shawn Wildermuth — Mon, 13 Feb 2023 00:00:00 +0000

This topic has been on my TODO: list for quite a while now. As I work with clients, many of them are just ignoring the warnings that you get from Nullable Reference Types. When Microsoft changed to make them the default, some developers seemed to be confused by the need. Here is my take on them:

I also made a Coding Short video that covers this same topic, if you’d rather watch than read:

https://www.youtube.com/watch?v=tMKcLwlhoEs

Before Nullable Reference Types

There has always been two different types of objects in C#: value types and reference types. Value types are created on the stack (therefore they go away without needing to be garbage collected); and Reference Types are created by the heap (needing to be garbage collected). Primative types and structs are value types, and everything else is a reference type, including strings. So we could do this:

int x = 5;
string y = null;

By it’s design, value-types couldn’t be null. They just where:

int x = null; // Error
string y = null;

There were occassions that we needed null on value types. So they introduced the Nullable<T> struct. Essentially, this allowed you to make value types nullable:

Nullable<int> x = null; // No problem

They did add some syntactical sugar for Nullable<T> by just using a question mark:

int? x = null; // Same as Nullable<int>

But why nullability? So you can test for whether a value exists:

int? x = null; 

if (x.HasValue) Write(x);

While this works, you could test for null as well:

int? x = null; 

if (x is not null) Write(x);

Ok, this is what Nullable value types are, but reference types already support null. Reference types do support being null, but do not support not allowing null. That’s the difference. By enabling Nullable Reference Types, all reference types (by default) do not support Null unless you use the define them with the question-mark:

object x = null // Doesn't work

But utilizing the null type definition:

object? x = null // works

As C# developers, we spend a lot of time worrying about whether an object is null (since anyone can pass a null for parameters or properties). So, enabling Nullable Reference Types makes that impossible. By default, new projects (since .NET 6) have enabled Nullable Reference Types by default. But how?

Enabling Nullable Reference Types

In C# 8, they added the ability to enable Nullable Reference Types. There are two ways to enable it: file-based declaration or a project level flag. For projects that want to opt into Nullable Reference Types slowly, you can use the file declarations:

#nullable enable
object x = null; // Doens't work, null isn't supported
#nullable disable

But for most projects, this is done at the project level:

<!--csproj-->
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net7.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

The <Nullable/> property is what enables the feature.

When you enable this, it will produce warnings for appling null to reference types. But you can even turn these into errors to force a project to address the changes:

<WarningsAsErrors>Nullable</WarningsAsErrors>

Using Nullable Reference Types

So, you’ve gotten this far so let’s talk some basics. When defining a variable, you can opt-into nullability by defining the type with nullability:

string? x = null;

That means anywhere you’re just defining the type (without inferring the type), C# will assume that null isn’t a valid value:

string x = "Hello";

if (x is null) // No longer necessary, this can't be null
{
  // ...
}

But what happens when we infer the type? For value types, it is assumed to be a non-nullable type, but for reference type…nullable:

var u = 15; // int
var s = ""; // string?
var t = new String('-', 20); // string?

This is actually one of the reasons I’m moving to the new syntax for creating objects:

object s = new(); // object - not nullable

Not exactly about nullable reference types, but in this case, the object is not null because we’re making sure it’s not nullable.

Classes and Nullable Reference Types

When clients have moved here, the biggest pain they seem to run into is with classes (et al.). After spending so many years writing simple data classes like so:

public class Customer
{
  public int Id { get; set;}
  public string Name { get; set;} // Warning
  public DateOnly Birthdate { get; set;}
  public string Phone { get;set;} // Warning
}

Properties that aren’t nullable are expected to be set before the end of the constructor. There are two ways to address make them nullable; and initalize the properties.

Making the properties nullable has the benefit of being more descriptive of the actual usage of the property:

public class Customer
{
  public int Id { get; set;}
  public string Name? { get; set;} // null unless you set it
  public DateOnly Birthdate { get; set;}
  public string Phone? { get;set;} // null unless you set it
}

Alternatively, you can set the value:

public class Customer
{
  public int Id { get; set;}
  public string Name { get; set;} = "";
  public DateOnly Birthdate { get; set;}
  public string Phone { get;set;} = "";
}

Or,

public class Customer
{
  public int Id { get; set;}
  public string Name { get; set;} 
  public DateOnly Birthdate { get; set;}
  public string Phone { get;set;} 

  public Customer(string name, string phone)
  {
    Name = name;
    Phone = phone;
  }
}

It may, at first, seem like trouble for certain types of classes. In fact, it’s is not uncommon to opt-out of nullability for entity classes:

#nullable disable
public class Customer
{
  public int Id { get; set;}
  public string Name { get; set;} // No Warning
  public DateOnly Birthdate { get; set;}
  public string Phone { get;set;} // No Warning
}
#nullable enable

Testing for Null

When you start using nullable properties on objects, you quickly run into warnings:

Customer customer = new();

WriteLine($"Name: {customer.Name}"); // Warning

The warning is because the compiler can’t confirm it is not null (Name is nullable). This is one of the uncomfortable parts of using Nullable Reference Types. So we can wrap it with a test for null (like you’ve probably been doing for a long time):

Customer customer = new();

if (customer.Name is not null)
{
  WriteLine($"Name: {customer.Name}");
}

At that point, the compiler can be sure it’s not null because you tested it. But this seems a lot of work to determine null. Instead we can use some syntactical sugar to shorten this:

Customer customer = new();

WriteLine($"Name: {customer?.Name}"); // Warning

The ?. is simply a shortcut. If Name is null, it jsut returns a null. This allows you to deal with nested nullable types pretty easily:

Customer customer = new();

WriteLine($"Name: {customer?.Name?.FirstName}"); // Warning

In this example, you can see that the ?. is used at multiple places in the code as Name could be null and FirstName could also be null.

This also affects how you will allocate a variable that might be null. For example:

Customer customer = new();

string name = customer.Name; // Warning, Name might be null

The null coalescing operator can be used here to define a default:

Customer customer = new();

string name = customer.Name ?? "No Name Specified"; // Warning, Name might be null

The ?? operator allows for the fallback in case of null. which should simplify some common scenarios.

But sometimes we need to help the compiler figure out whether something is null. You might know that a particular object is not null even if it is a nullable property. There is an additional syntax that supports telling the compiler that you know better. Just use the ! syntax.

Customer customer = new();

string name = customer.Name!; // I know it's never null

This just tells the compiler what you expect. If the Name is null, it will throw an exception…so only use it when you’re sure. The bang symbol (e.g. !) is used at the end of the variable. So if you need to string these, you’ll put the bang at each level:

Customer customer = new();

string name = customer.Name!.FirstName!; // I know they're never null

While using Nullable Reference Types could be seen as a way to over-complicate your code, these bits of syntactical sugar can simplify dealing with nullables.

Generics and Nullable Reference Types

Just like any other code, you can use the question-mark to specify that a value is nullable:

public class SomeEntity<TKey>
{
  public TKey? Key { get; set; }
}

The problem with this is that the type specified in TKey could also be nullable:

SomeEntity<string?> entity = new();

But this results in a warning because you can’t have a nullable of a nullable. The generated type might look like this:

public class SomeEntity<string?>
{
  public string?? Key { get; set; }
}

Notice the double question-mark. It also suggests that the generic class doesn’t quite know whether to initialize it or not since it doesn’t know about the nullability. To get around this, you can use the notnull constraint:

public class SomeEntity<TKey> where : notnull
{
  public TKey? Key { get; set; }
}

That way the generic type can be in control of the nullability instead of the caller.

Conclusion

I hope that this quick intro into Nullable Reference Types helps you get your head around the ‘why’ and ‘how’ of Nullable Reference Types. Please comment if you have more questions and/or complaints!

Nullable Reference Types Example

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

Using Vite's Plugin for Progressive Web Apps (PWAs)

Shawn Wildermuth — Thu, 09 Feb 2023 00:00:00 +0000

I’ve worked with Progressive Web Application plug-ins with several SPA frameworks. Most of them are pretty simple to implement. But when I learned about Vite’s plug-in, I was intrigued since that would work across different SPA frameworks. Let’s take a look at it.

I also made a Coding Short video that covers this same topic, if you’d rather watch than read:

The Vite plug-in for PWA works at the Vite/Build level, not for your specific framework (or lack of a framework). That means it will work for Vue, React, SvelteKit and Vanilla JS (and any other Vite-powered development). Before we do any of this, we have a working website:

To install it, you just need to add it to your development-time dependencies:

> npm i vite-plugin-pwa --save-dev

Once installed, you can add it to your vite.config.js file:

...
import { VitePWA } from "vite-plugin-pwa";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    vue(),
    VitePWA()
  ],
  ...
})

With this installed, you’ll see that your builds will generate some extra files:

build started...
✓ 30 modules transformed.
../wwwroot/registerSW.js 0.13 kB
../wwwroot/manifest.webmanifest 0.14 kB
../wwwroot/index.html 0.56 kB
../wwwroot/assets/index-cfd5afe3.css 7.14 kB │ gzip: 1.97 kB
../wwwroot/assets/index-25653f73.js 75.09 kB │ gzip: 30.04 kB
built in 1378ms.

PWA v0.14.1
mode generateSW
precache 5 entries (80.98 KiB)
files generated
  ..\wwwroot\sw.js
  ..\wwwroot\workbox-519d0965.js

The file generated by the plug-in include:

manifest.webmanifest : Metadata about the app and an indication that it can be installed.
sw.js : A, required, service worker that supports running as an app (and offline).
registerSW.js : A new script that Vite injects into the index.html that registers the service worker.
workbox-*.js : Workbox specific code to support the PWA.

With this generated, you should see the “install icon” on supported browsers:

You can customize the metadata that is used by just adding a metadata object in the plug-in:

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    vue(),
    VitePWA({      
      manifest: { 
        icons: [
          {
            src: "/icons/512.png",
            sizes: "512x512",
            type: "image/png",
            purpose: "any maskable"
          }
        ]
      }
    })],
...

The properties that you can customize in the manifest are all defined here.

If you run the example now, you can look at the manifest for errors or omissions:

If you click on the Application tab in the tools, you can see that it is complaining about missing icons for different operating systems.

If you switch to the Service Worker, you can see it is running:

But how does this work? The Service Worker can intercept network requests and serve the content necessary to load up the project. In fact, if you look at the “Cache Storage”, you’ll see the standard cache of the web page’s files:

The feature of the browser that supports all of this is called workbox, so if you look at that cache, you’ll see the files that are being cached to load this offline (including .html, .js, .css, etc.). So, let’s try and making the app offline to see what happens:

You can go offline in the Network tab by changing the networking to offline. If you refresh the page, you’ll get something that looks like this:

But what happened? The cache (see earlier) is only caching the files needed to serve the page, not for any functionality.

How do we fix this? Luckily, the plug-in supports changing the workbox settings to create your own caches (called runtimeCaching). To do this we return back to the vite.config.js file:

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    vue(),
    VitePWA({
      manifest: {
        icons: [
          {
            src: "/icons/512.png",
            sizes: "512x512",
            type: "image/png",
            purpose: "any maskable",
          },
        ],
      },
      workbox: {
        runtimeCaching: [
          {
            urlPattern: ({ url }) => {
              return url.pathname.startsWith("/api");
            },
            handler: "CacheFirst" as const,
            options: {
              cacheName: "api-cache",
              cacheableResponse: {
                statuses: [0, 200],
              },
            },
          },
        ],
      },
    }),
  ],'
...

By creating a section for workbox, we can configure a number of things, but for us we want to create an API cache. You can see that i’m testing all requests for /api and caching all GETs into our own cache. By enabling this, the customers reappear. We can see (and interrogate) the cache in the Application tools:

This sort of all encompassing cache might not be realistic, but you could be caching non-volatile API calls. This isn’t a solution for handling offline changes. You can use application-specific code to write it to session or local storage.

I hope you’ve seen how the Vite PWA plug-in works anbd how you can use it to install your website as a local application!

You can find the example of the project here:

Module Example

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

What Surprised Me About ECMAScript Modules

Shawn Wildermuth — Wed, 01 Feb 2023 00:00:00 +0000

I’ve spent the last couple of months working on a new Pluralsight course about Modules in JavaScript. I’ve been writing JavaScript (and TypeScript) for a lot of years. But digging into the course made me understand how some of this modularity actually worked. Let’s talk about some things that surprised me.

I also made a Coding Short video that covers this same topic, if you'd rather watch than read:

Coding Short Video

ECMAScript Modules in Node.js

While Node.js has had module support long before ECMAScript got it’s act together and started supporting modules. CommonJS was an early standard for exposing modules. So most of the Node.js projects i’ve worked on just supposed that I had to use CommonJS. For example, a simple import using CommonJS (e.g. require()):

// index.js
const invoices = require("./invoices.js");

Since EMCAScript Modules (ESM) are supported, you could just name your index.js (in our case) to index.mjs and it would allow us to use EMCAScript:

// index.mjs
import invoices from "./invoices.mjs";

But, for me, I like that Node.js allows us to change the default module type to ESM:

{
  "name": "before",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "type": "module", // commonjs is the default
  "scripts": {
    "start": "node ./index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "lodash": "^4.17.21"
  }
}

Then we can just use ESM in our code without the renaming:

// index.js
import invoices from "./invoices.js";

Consuming CommonJS from ECMAScript

So, you can use ESM to load all your own code where you’ve defined your modules directly. This works with your own projects or npm packages. If you’re using it for your own projects, you can rename your project to .cjs and it will be treated as a CommonJS:

// invoices.cjs
module.exports = [...];

But, more commonly, npm packages are mostly defined as CommonJS modules. How do we use them? For example, we can bring in a npm package (in this case lodash) like so:

import lodash from "lodash";

This allows us to use the lodash object as you like. But there is a limitation. Ordinarily, you could destructure it to get just the round function we need:

import { round } from "lodash";

But ESM with Node.js, it doesn’t work. It is because of a fundamental difference in how CommonJS defines named element and how ESM does it. So, to do it, you will need to import it as the default, but then you can destructure manually:

import lodash from "lodash";
const { round } = lodash;

It’s a minor nit, but if you know how CommonJS modules defined names (as I show in my course), it actually makes sense.

Deferred Imports

I’ve been using ESM for a while and never ran into the import() function. I used to think that CommonJS was the only module system that allowed for late binding imports. But, alas, I was wrong.

The import function allows you to request an import at runtime, though it is asynchronous so you have to deal with the promise. For example:

export async function calculateTotal(invoice) {
  const { taxRates } = await import("./taxRates.js");
  const rate = taxRates[invoice.state];
  const total = invoice.amount + invoice.amount * rate;
  return {
    rate,
    total,
  };
}

You can see that the import allows you to load the module the first time we use calculateTotal(). This does mean that you have to deal with asynchrony with the caller too:

invoices.forEach(async i => {
  const { rate, total } = await calculateTotal(i);
  console.log(`Invoice: ${i.invoiceNumber}, Date: ${i.invoiceDate}
  Gross: $${round(i.amount,2)}
  Tax Rate: ${rate * 100}% 
  Net: $${round(total,2)}`);
});

Note that the foreach is now async and you can use await to deal with the asynchrony.

You can find the example of the project here:

Module Example

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

Generating Sample Data with Bogus

Shawn Wildermuth — Sun, 29 Jan 2023 00:00:00 +0000

Most of my job these days is creating tutorials or examples. This means I often start from scratch with a new type of project. I usually just cruft up some sample data for my project to start. While investigating some alternatives to Automapper (video and blog coming soon), I wanted to be able to create a bunch of sample data. I, luckily, ran into a tool that I was surprised I’d never heard of: Bogus. Let’s talk about it.

I also made a Coding Short video that covers this same topic, if you’d rather watch than read:

What is Bogus?

Bogus is a library that works with C#, F# and VB.NET that can be used to create repeatable, fake data for applications. It is somewhat a port of a similar library Bogus.js. It accompished this by creating generators (called Fakers) that have a set of rules for generating one or more fake objects. Built-into Bogus is a set of generalized rules for common data categories (i.e. Addresses, Companies, People, Phone Numbers, etc.). Enough talk, let’s see how it works. The full repo is at:

Bogus

To install Bogus, you can use the Package Manager or just the dotnet CLI:

> dotnet add package Bogus

Creating a Faker

You start out by creating an instance of a class called Faker<T>. From that class you would use a fluent syntax to set up rules on creating sample data. But let’s start with our POCO for a Customer:

public class Customer
{
  public int Id { get; set; }
  public string? CompanyName { get; set; }
  public string? Phone { get; set; }
  public string? ContactName { get; set; }
  public int AddressId { get; set; }
  public Address? Address { get;set;}
  public IEnumerable<Order>? Orders {get;set;}
}

You can notice that aside from simple properties, we have a one-to-one relationship to an Address and a one-to-many relationship with Orders. Let’s start by creating a faker for the Customer object and the simple properties:

var customerFaker = new Faker<Customer>();

We can then use the RuleFor method to specify a rule for the Company Name:

var customerFaker = new Faker<Customer>()
  .RuleFor(c => c.CompanyName, f => f.Company.CompanyName())

The first parameter of the RuleFor method is a lambda to pick the property on Customer that I want to fake. The second parameter is another lambda to pass in how to generate the property. While we could write any code we need here, the most-common case is to use the Faker object passed to use the built-in semantics. In this case we are using the Company category to generate a company name.

If we continue this, we can fake more simple properties like so:

var customerFaker = new Faker<Customer>()
  .RuleFor(c => c.CompanyName, f => f.Company.CompanyName())
  .RuleFor(c => c.ContactName, f => f.Name.FullName())
  .RuleFor(c => c.Phone, f => f.Phone.PhoneNumberFormat());

You can see here that we’re using the Name category and the Phone category. The Bogus library has a large set of these built-in semantics. Sometimes we’ll need to use custom code to generate data we need. For example, we’ll want to generate IDs for the generated customers. One strategy is to just create a local integer and assign it with simple code:

var id = 1;

var customerFaker = new Faker<Customer>()
  .RuleFor(c => c.Id, _ => id++)
  .RuleFor(c => c.CompanyName, f => f.Company.CompanyName())
  .RuleFor(c => c.ContactName, f => f.Name.FullName())
  .RuleFor(c => c.Phone, f => f.Phone.PhoneNumberFormat());

Here we can see that we just have an integer (which will become a closure to the rule) and we just increment it everytime a new customer is created.

To use the Faker, we can just call Generate() with how many you want:

var customers = customerFaker.Generate(1000);

This will create a thousand fake customers.

Repeatable Fake Data

By default, the generation of customers is random. So that everytime you create an instance of the Faker object (e.g. new Faker<Customer>), you would get different customers. When you want a consistent set of fake data, you can use a seeder to ensure that you get the same data every time. To do this, you just need to set a seed value to the same number:

public class CustomerFaker : Faker<Customer>
{
    public CustomerFaker()
  {
    var id = 1;

    UseSeed(1969) // Use any number
      .RuleFor(c => c.Id, _ => id++)
      .RuleFor(c => c.CompanyName, f => f.Company.CompanyName())
      .RuleFor(c => c.ContactName, f => f.Name.FullName())
      .RuleFor(c => c.Phone, f => f.Phone.PhoneNumberFormat());
  }
}

var customers = new CustomerFaker().Generate(1000);

When you do this, you can guarantee to get the same customers. But this affects the entire instance of the faker. This is because every call to Generate will generate the next set of faked data. For example:

var customerFaker = new CustomerFaker();

var customers = customerFaker.Generate(1);
var companyName = customers.First().CompanyName;

var newCustomers = customerFaker.Generate(1);

Assert.IsTrue(companyName == newCustomers.First().CompanyName); // FAILS

This is because the seed is the repeatable data is per-instance. So that the the first call to Generate will give you the first repeatable object; and the second call to Generate gives you the second object.

But if you create a new instance, the names will be guaranteed:

var customerFaker = new CustomerFaker();

var customers = customerFaker.Generate(1);
var companyName = customers.First().CompanyName;

var newFaker = new CustomerFaker();
var newCustomers = newFaker.Generate(1);

Assert.IsTrue(companyName == newCustomers.First().CompanyName); // TRUE

This support the idea of repeatable sample data!

Creating Related Sample Data

In our Customer class, we have a property for an Address. We can create a Faker for the Address too:

public class AddressFaker : Faker<Address>
{
  public AddressFaker()
  {
    var id = 0;
    UseSeed(1969)
      .RuleFor(c => c.Id, f => ++id)
      .RuleFor(c => c.Address1, f => f.Address.StreetAddress())
      .RuleFor(c => c.Address2, f => f.Address.SecondaryAddress())
      .RuleFor(c => c.City, f => f.Address.City())
      .RuleFor(c => c.StateProvince, f => f.Address.State())
      .RuleFor(c => c.PostalCode, f => f.Address.ZipCode());
  }
}

Again, there is a category for the type of data we need and can decide how to generate sample addresses. One thing you might want is to optionally not create certain parts of the fake data. For example, for our addresses, I want some of the Address2 properties to be null to replicate some apartment/suite numbers and addresses that do not have them. To do this, you can use OrNull() method:

.RuleFor(c => c.Address2, f => f.Address.SecondaryAddress()
                                        .OrNull(f, .5f))

The OrNull method takes the faker object and a value between 0 and 1 to determine how often to generate a null value. In this example, we’re specifying that we want half (or 50%) of the Addresses to have a null for it’s secondary address.

Now that we have a faker that does what we want, let’s use it to generate addresses too!

public class CustomerFaker : Faker<Customer>
{
  AddressFaker _addrFaker = new AddressFaker();

    public CustomerFaker()
  {
    var id = 1;

    UseSeed(1969) // Use any number
      .RuleFor(c => c.Id, _ => id++)
      .RuleFor(c => c.CompanyName, f => f.Company.CompanyName())
      .RuleFor(c => c.ContactName, f => f.Name.FullName())
      .RuleFor(c => c.Phone, f => f.Phone.PhoneNumberFormat())
      .RuleFor(c => c.Address, _ => _addrFaker.Generate(1)
                                              .First()
                                              .OrNull(_, .1f));
  }
}

You can notice that we’re creating an instance of the AddressFaker and then using it when we specify the rule for the Customer’s Address property. We can even use OrNull to only generate Addresses for 90% of the customers.

There is a lot more to the Bogus library, but hopefully this will get you started. To get the example code from the video and this blog post, see the Github Repo:

FixingIt Code

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

Vite-Powered SPAs in ASP.NET Core Projects

Shawn Wildermuth — Wed, 18 Jan 2023 00:00:00 +0000

If you’ve heard me talk about Vite in the past (and so commonly mispronouce it), you know I am a fan. With many Vue, React and SvelteKit applications are moving to Vite, I’ve been investigating how to integrate it for development and production into ASP.NET Core applications. Let’s see what I found out.

I also made a Coding Short video that covers this same topic, if you’d rather watch than read:

https://www.youtube.com/watch?v=8c73j7RHoSQ

Short Intro to Vite

Normally, we’ve used packagers (Webpack, Rollup) to at development-time to watch for changes and hot-swap or reload pages as necessary. For development time, approaches this differently. While Vite also does hot-swapping of code, but it approaches this with actually compiling the project. Instead it exposes a server for a project that relies on script modules.

For example, to start a project, you need to just point at the entry file:

<body>
  <div id="app"></div>
  <script type="module" src="/src/main.js"></script>
</body>

Most modern browsers now support the script-type of module. In this case, Vite loads the main.js and then just follows imports and exports to load all the parts of the project that you need. This means that startup is incredibly fast since there really isn’t any compilation step.

When you’re developing directly with Vite, you can just start it at the command-line and it will server the index.html as well as the script/resource files. Though Vite isn’t really a production ready web-server. The serving of the files is really to have a great development-time experience.

For production time, it still compiles projects (by default with Rollup) in the same way that these frameworks have always done.

With this different approach, integrating with ASP.NET Core presents some challenges.

Integrating a Vite project for Production

A little background: our project is a simple ASP.NET Core project with a Vite project as a subdirectory called “Client”:

Before we talk about how to get Vite working for development, let’s talk about how it will work when you publish your app for production (or other non-development builds).

In a Vite project, you can use Vite to build your project by using the build command (shown here in a package.json file’s scripts):

  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },

Vite uses Rollup (by default) to build and package your project for production. So we can configure Vite to output our project by modifying the vite.config.js file and adding a build configuration:

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue()],
  build: {
    outDir: "../wwwroot/client",
    emptyOutDir: true
  },
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  }
})

The outDir is pointing at our wwwroot folder where the ASP.NET Core project will have access to the build files. The emptyOutDir is specifically to empty it before building so you don’t get any extra assets littering that folder.

When we build the project, we get several files generated:

vite v4.0.4 building for production...
✓ 31 modules transformed.
../wwwroot/client/index.html 0.45 kB
../wwwroot/client/assets/index-ca646b5b.css 1.22 kB │ gzip: 0.48 kB
../wwwroot/client/assets/index-bdf9da80.js 77.78 kB │ gzip: 30.96 kB

Then we can just reference these files in the host page (a Razor page in this example):

@page
@section Styles {
  <link rel="stylesheet" 
        href="/client/assets/index-ca646b5b.css">
}
@section Scripts {
  <script src="/client/assets/index-bdf9da80.js">
  </script>
}
<h1>Film List</h1>
<div id="app"></div>

Notice that we’re also adding any markup (the div#app in this example) that the Vite project needs.

But we have a problem, the Vite build is giving a cache-busting name (the random string after index-). On every build, this will change, so we can use a special tag helpers:

@section Styles {
  <link rel="stylesheet" 
        asp-href-include="/client/assets/index-*.css">
}
@section Scripts {
  <script asp-src-include="/client/assets/index-*.js">
  </script>
}

By using the asp-href-include and asp-src-include tag helpers, we can use a wildcard to include the right files for us.

Lastly, we need to actually run the build. We can do this by just adding the build to the .csproj file. By adding a Target for before publish, we can just execute the build:

<Target Name='CompileClient' 
        BeforeTargets="Publish"> 
  <Exec WorkingDirectory="./client" 
        Command="npm install" />
  <Exec WorkingDirectory="./client" 
        Command="npm run build" />
</Target>

Notice that we’re calling npm install first to be sure that all the packages exist. And that we’re using the WorkingDirectory to specify our client directory.

Now, when you publish the project (manually or in a build script), the Vite project is built too!

But we came to talk about development, let’s talk about that next.

Integrating Vite for Development

Like we saw earlier, during development, you would run Vite and it would load scripts on demand using the type=module method. When you run Vite in this mode, it is essentially running a server for the markup and a single, large SPA. If you’re creating APIs with ASP.NET Core and just hosting your SPA as a single HTML file, this works perfectly.

NOTE: There is a package called Microsoft.AspNetCore.SpaServices.Extension that is meant to do this, but it is not well documented and may be depreciated by now. It didn’t work well with Vite, though it might for Angular and React using their CLIs

But in many cases, you’ll want to host one or more SPAs on specific pages of your project. How do we handle this since both ASP.NET Core and Vite will be serving files?

During development you’ll want to run both servers, and just use the vite serving for the assets (.js/.css) for your project. To do this, let’s look at the Razor page again:

@page
@section Styles {
  <link rel="stylesheet" 
        asp-href-include="/client/assets/index-*.css">
}
@section Scripts {
  <script asp-src-include="/client/assets/index-*.js">
  </script>
}
<h1>Film List</h1>
<div id="app"></div>

What we want to do here is only use these styles and script tags during production, so we can surround it with an environment tag for production:

<environment include="Production">
@section Styles {
  <link rel="stylesheet" 
        asp-href-include="/client/assets/index-*.css">
}
@section Scripts {
  <script asp-src-include="/client/assets/index-*.js">
  </script>
}
</environment>

This will set it up to only use the build assets during production. We can then add an environment tag for development:

<environment include="Development">
  <script type="module" 
          src="http://localhost:5000/src/main.js"></script>  
</environment>

You’ll notice that we’re using the Vite server to serve the main.js file. If you remember from earlier, this will load other assets on-demand and hot-swap them as necessary.

In this way you get the best of both worlds. But we have a problem:

Dealing with Routing in Vite Projects

In our example, we’re hosting the SPA on a page who’s URL is http://localhost:8000/FilmList. This is related to the Razor page’s URL. But our Vite project (Vue in this case) is using history-type routing. That means, when it navigates, it takes over the URL. So when we navigate to our SPA’s home page, it changes it to http://localhost:8000/ and for the list page it changes the URL to http://localhost:8000/films (which are based on the projects own routing, not server-side routing).

The problem is if we refresh the page or open that URL, it fails because we’re not serving up our Razor page at those URLs. There are two fixes here. First, we need to tell the Vite project what the base address for our project is. We can do this in vite.config.js:

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue()],
  base: "/FilmList",
  build: {
    outDir: "../wwwroot/client",
    emptyOutDir: true
  },
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  }
})

You can see the addition of the base property which let’s the app know what the base URL for the project is. In this way, the navigation will start at that base URL. This is better. But then our SPA’s route for the list of films is http://localhost:8080/FilmList/films. But this isn’t a valid server-route either. We need a way to have inter-SPA URLs serve the SPA page (and the internal routing do the right thing).

To do this, you can simply use fallback routes in the ASP.NET Core server. You’ll want to make sure that any fallbacks are specified after all your other routes (e.g. Razor Pages, Controllers and Minimal APIs). You to this by using the MapFallback calls. For example, in our case (since we’re using Razor pages) we can use MapFallbackToPage like so:

app.MapGet("api/films", async (BechdelDataService ds, int? page, int? pageSize) =>
{
  //...
}).Produces<IEnumerable<Film>>(contentType: "application/json").Produces(404).ProducesProblem(500);

app.MapFallbackToPage("/FilmList");

app.Run();

Note, that this fallback is not redirecting, but just serving that page. That way the URL is preserved for the Vite project to use for it’s own routing.

This will fallback to any page that isn’t found in routing to the FilmList Razor page that contains our SPA. That might be too broad though, you may want to use the fallback with a pattern too (so it only falls back to that page’s URLs) like so:

app.MapFallbackToPage("/FilmList/{*path}", "/FilmList");

The first parameter of the MapFallbackToPage allows you to specify a routing pattern to apply this fallback to. In this way, any urls that start with /FilmList will just fallback to that page.

I hope this helps some of you using Vite for your own projects. You can get the example for this project at:

https://github.com/shawnwildermuth/codingshorts/tree/main/aspnetvite

I’m happy to answer any of your questions below if I’ve been unclear about any of this!

Thanks for reading.

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

More on .NET 7 user-jwts Tool

Shawn Wildermuth — Tue, 10 Jan 2023 00:00:00 +0000

I recently released a Coding Short video and a blog post about the new JWT Tooling in .NET 7. It was received well, but I didn’t dig into some of the real details of what is happening. If you need to catch up, here is the blog post:

Changes in JWT Bearer Tokens in .NET 7

What I didn’t have a chance to explain is everything that the user-jwts tool actually does. It makes several changes:

Adds a section to the appsettings.developer.json file to add user-jwts as a valid issuer of JWTs.
Adds secret key related properties to the user-secrets for the project.

What it doesn’t do is wire up your startup to include JwtBearer authentication, it only sets up the tool as an issuer of the JWT. Let’s walk through this.

AppSettings.Developer.json

The first step is it adds a new Authentication section to the developer settings:

  "Authentication": {
    "Schemes": {
      "Bearer": {
        "ValidAudiences": [
          "http://localhost:38015",
          "https://localhost:44384",
          "http://localhost:5241",
          "https://localhost:7254"
        ],
        "ValidIssuer": "dotnet-user-jwts"
      }
    }
  }

It gets the valid audiences by looking at the launchsettings.json (in the Properties folder) of your project. The ValidIssuer is there to match the issuer of the JWT as configured in user settings (see next section for what I mean).

User Secrets

In order to allow the JWT to be signed, it needs to have some security information. This information is in the user-secrets file. If your project didn’t have support user-secrets yet, the tool adds the user-secret GUID to the project and then stores some information there. To see what they added, just list the secrets in this project:

> dotnet user-secrets list

In my case, this returns the secret and valid issuer information (this is a throw-away project, so leaking this secret doesn’t matter):

Authentication:Schemes:Bearer:SigningKeys:0:Value = R98yic+EGjR0asjN8eHe2nSLlhBB8tWcebIxHmcOSko=
Authentication:Schemes:Bearer:SigningKeys:0:Length = 32
Authentication:Schemes:Bearer:SigningKeys:0:Issuer = dotnet-user-jwts
Authentication:Schemes:Bearer:SigningKeys:0:Id = e1b964aa

What’s interesting here, is that some of these defaults are configurable. By default, when the tool issues a JWT, it uses your machine name identification. If you don’t want that, you can simply override it:

> dotnet user-jwts create -n shawn@aol.com

You can even change the name of the Issuer with:

> dotnet user-jwts create -n shawn@wildermuth.com --scheme YourIssuerName

I was able to use this information to just prototype issuing JWTs (via API) to just re-use the tools’ information. You can see here the GetSection matches the information in user-secrets:

var bearer = _config.GetSection("Authentication:Schemes:Bearer");
if (bearer is not null)
{
  var uniqueKey = bearer.GetSection("SigningKeys")
    .Get<SymmetricSecurityKey[]>()?
    .First()
    .Key;
  var issuer = bearer["ValidIssuer"];
  var audiences = bearer.GetSection("ValidAudiences")
    .Get<string[]>();
  var key = new SymmetricSecurityKey(uniqueKey);
  var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256Signature);

Hope this answers some questions. Ping me below if you have questions!

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

Changes in JWT Bearer Token Setup in .NET 7

Shawn Wildermuth — Wed, 07 Dec 2022 12:00:00 +0000

If you’ve taken my “Building an API with ASP.NET Core” course over at Pluralsight, one of the more complicated tasks is to add support for JWT Bearer tokens. In .NET 7, they’ve simplified this quite a bit. Let’s take look.

Instead of showing you how it used to work, let’s just talk about how to add JWT Bearer tokens to a new project. I started out with a simple Web API project (controller-based), though this technique is identical for gRPC or Minimal APIs. When we start out, authorization isn’t even enabled (unless you chose for it to scaffold authorization), but I’m going to assume that Program.cs looks similar to this:

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddControllers();
// ...
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

The only hint about Authorization is the UseAuthorization which is just the middleware to check for any Authentication Schemes that are added. You might also note that there is not a UseAuthentication any longer. It is no longer necessary to include both.

So let’s support JWT Bearer Tokens. First we still need to add the package to our project:

> dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer

Once added, we can wire up authentication:

builder.Services.AddAuthentication();

One thing to note here is that you do not need to specify a default scheme any longer (the first scheme is assumed default). So we can call the AddJwtBearerToken call that you might be used to:

builder.Services.AddAuthentication()
                .AddJwtBearer();

Ordinarily, you would need to configure the token here but finally we have sensible defaults. We’ll get back to configuring it. But first, let’s head over to the Controller Action and add that magic Authorize attribute (just like before):

[ApiController]
[Route("[controller]")]
[Authorize]
public class WeatherForecastController : ControllerBase

So if we open the API, we get:

Don’t worry, that’s what was supposed to happen!

Since we setup JWT Bearer tokens, we should be able to just add a token to the request and it should work. But how do we get a token? Ah, another gem inside .NET 7: dotnet user-jwts. The user-jwts took is all about being able to look at a project and build a developer JWT from the configuration. Yes, this means you don’t have to build your API for returning tokens until you actually need to. To use it just call the create sub-command:

>dotnet user-jwts create

It will spit out:

Token: eyJhbGciOiJI...QpMdl0LRL7w1f1cnEu7dwJMvw4eSi1px56dneQ5tOQg

No, this isn’t really my token. But you’ll see that it will paste out an entire JWT Bearer token that we can then use in the request testing:

Last note, we can still configure the JWT Bearer token, but now we can use configuration like adults. In fact, the user-jwts tool will add a section in your development appsettings.json file the first time you create a JWT:

  "Authentication": {
    "Schemes": {
      "Bearer": {
        "ValidAudiences": [
          "http://localhost:64693",
          "https://localhost:44317",
          "http://localhost:5124",
          "https://localhost:7125"
        ],
        "ValidIssuer": "dotnet-user-jwts"
      }
    }
  }

Your exact settings will be a little different, but you can see that you can specify all the JWT settings here in configuration. Since this is in the appsettings.development.js file, those tokens created by user-jwts will never work in production as an added security gate (see how the ValidIssuer is the user-jwts tool). In fact, if we decode our JWT that it generated, we can see that it doesn’t have anything special except for machine user name which it uses as the unique id:

{
  "unique_name": "shawn",
  "sub": "shawn",
  "jti": "be38d021",
  "aud": [
    "http://localhost:64693",
    "https://localhost:44317",
    "http://localhost:5124",
    "https://localhost:7125"
  ],
  "nbf": 1670459953,
  "exp": 1678235953,
  "iat": 1670459954,
  "iss": "dotnet-user-jwts"
}

Most of this should look familar! Let me know what you think!

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

C# 11 Strings in the Raw

Shawn Wildermuth — Sat, 26 Nov 2022 12:00:00 +0000

With the release of C# 11, there is a new string in town. It might be getting crazy, but this new “Raw String Literals” is something interesting. Before we dig in, let’s have a refresher about strings:

Simple Strings

Every language needs a type for storing text, that’s the String class/ string keyword. It’s what is used mainly in C# and has been there since day 1:

var text = "I thought we had literal strings";
WriteLine(text);

We could use embedded quotes, but we needed to escape them (or other things like tabs, line breaks):

text = "John \"Quincy\" Adams";

We didn’t have a good solution for multi-line, so we ended up with monstrosities (or using a StringBuilder ):

text = "First Line\n";
text += "Second Line\n";
text += "Third Line";

String Interpolation

Some time, later C# introduced a way to have strings just use interpolation (instead of the dreaded string.Format(…)):

text = $"This is an interpolated string: {someName} - {someName.Length}";

The dollar sign said that it should expect C# code inside brackets.

But this introduced a need to double bracket if you needed a bracket in string:

text = $"This is an interpolated string: {{ {someName} }}";

A compromise to support this better way of building strings. Of course, that made JSON in strings pretty ugly:

text = $"{{ \"name\": \"Shawn\" }}";

Verbatim Strings

In came Verbatim strings. This allowed you to have line breaks and look simpler:

text = @"This is a verbatim string.

This means you can have line breaks 
and use double ""'s to output quotes.";

While many things didn’t need to be escaped, you still needed something special for double-quotes. If you needed double-quotes you had to double them to get:

This is a verbatim string.

This means you can have line breaks
and use double "'s to output quotes.

Not perfect, but worked in a lot of situations, but if you wanted to use a format like XML or JSON, it ended up with this ugliness:

text = @
{
  ""name"": ""Shawn"
}
";

Verbatim Strings with Interpolation

But you could mix verbatim and interpolation:

text = $@"This is a verbatim 
interpolated string: {someName}";

This worked, unless you needed brackets as text:

// Doesn't work, as it thinks that the whole thing is interpolated
text = $@"
{ 
  ""name"": ""{someName}"" 
}";

So, now we need to double-quote as well as double curly-brace:

// Works
text = $@"
{{ 
  ""name"": ""{someName}"" 
}}";

Hrmph…

Ok, Raw String Literals?

Here’s where Raw String Literals come in. The idea is to allow anything between a set of delimiters. That delimiter is a triple-quote (yes, seriously, but it does make sense).

When you triple-quote, everything is a literal, No magic here:

text = """This is pure text, which includes " and ' and other literals""";

This works, but the rules are a tad different for multi-line, in that case the triple-quotes must be on their own lines:

text = """
Everything between the quotes is literally interpreted, 
There is no need for escaping of anything.

Really!
  You can use "Whatever you Like"
""";

What’s important here is that the triple-quoted lines are not included in the string. The string starts on the first line after the triple-quote. This solves a lot of the messiness with commonly used things like JSON:

text = """
{
  "name": "Shawn"
}
""";

Whew, that’s easy…almost.

Interpolated Raw String Literals?

If you add interpolation to a raw string, you find an odd situation where the compiler must know what is an interpolated section (Raw String Literals assume everything is just text). Like the other types of strings, you start interpolated strings with a dollar sign:

text = $"""<name>{someName}</name>""";

Simple, sure. But what if you need brackets?

// Doesn't work, as it's expecting the brace
// to be part of the interpolation
text = $""" 
{
  "name": "{someName}"
}
""";

The solution? To do interpolation with brackets, the number of dollar-signs represents the number of brackets to indicate an interpolation:

// Add number of $ for the depth of the braces needed
text = $$"""
{
  "name": "{{someName}}"
}
""";

This isn’t a typo, this is valid C# 11. Solves a ton of situations, but still requires you to remember some stuff (I actually wish that had used the back-tick like JavaScript as it reads easier IMO).

What do you think of new new syntax (and do you think you’ll be using it?) Tell me in the comments!

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.

New Videos: Coding Short and a Rant

Shawn Wildermuth — Mon, 31 Oct 2022 00:00:00 +0000

I can’t believe October is almost over! I forgot to post about a couple of videos I made this month. The first one is about new features in .NET 7 for Minimal APIs. The second one is a rant(ish) about support terms for Open Source projects (including .NET). Take a gander:

https://www.youtube.com/watch?v=8c73j7RHoSQ
https://www.youtube.com/watch?v=oR4dELwe57Q

Subscribe to my YouTube Channel

This work by Shawn Wildermuth is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Based on a work at wildermuth.com.

If you liked this article, see Shawn's courses on Pluralsight.