DEV Community: Jamie Nordmeyer

Open Source Project Updates

Jamie Nordmeyer — Sun, 03 Mar 2024 23:06:11 +0000

I’ve updated two of my open-source projects for those who might care, moving them both up to .NET 8.

The first is the dotnet GUID tool, which is documented here and found here on Github. There were no changes made to this project other than to update it to .NET 8.

The second is the Clean Architecture solution template for dotnet new. This is documented here and found here on Github.

Neither release changed functionality, and the code was only changed in the Clean Architecture solution to remove a couple warnings related to the move to .NET 8. Both projects also had their Nuget package dependencies updated to latest and greatest at the time of their most recent commits.

Using Angular Signals for Global State

Jamie Nordmeyer — Sat, 29 Jul 2023 21:13:05 +0000

With the release of Angular 16 we got access to the new Signals API, along with a host of other features. They are currently in developer preview meaning that they could technically change between now and the next release of Angular. However, you can use them now, and they provide a much cleaner way to have reactive code in your web application. They DO not replace RxJS Observables; Angular services like HttpClient and resolvers still rely on RxJS. However, they do provide another tool in the box for responding to changes in your application that are often easier to understand than the RxJS alternative.

Code With RxJS

In an application that I’m working on, before Angular 16 shipped, I was using a custom StoreService to hold global application state. I’ve tried libraries like NgRx and Akita to manage global state, but found them to be way too heavy-handed for what I wanted (not saying ANYTHING negative towards these libraries; not every tool is right for every job, and the authors of these libraries would probably be the first to tell you that). This custom StoreService was created using RxJS, and looked like this:

import { Injectable } from '@angular/core';
import { ApplicationState } from '@shared/models';
import { UserCard } from '@shared/models';
import { BehaviorSubject, map } from 'rxjs';

const initialState: ApplicationState = {
  userCard: null,
};

@Injectable({
  providedIn: 'root',
})
export class StoreService {
  private readonly store$ = new BehaviorSubject<ApplicationState>(initialState);
  readonly userCard$ = this.store$.pipe(map((state) => state.userCard));

  setUserCard(userCard: UserCard | null) {
    this.store$.next({
      ...this.store$.value,
      userCard: userCard,
    });
  }
}

Here, the UserCard interface represents the basic details of the logged-in user, things like name and data points for putting together a URL to their Avatar image. When I wanted to retrieve the user card for the logged-in user, a service would be used:

import { Inject, Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { catchError, mergeMap, Observable, of, tap } from 'rxjs';
import { StoreService } from '@shared/services';
import { UserCard } from '@shared/models';

@Injectable({
  providedIn: 'root',
})
export class UserCardService {
  constructor(
    private http: HttpClient,
    private storeService: StoreService,
    @Inject('API_BASE_URL') private baseUrl: string
  ) {}

  getUserCard(): Observable<UserCard | null> {
    return this.storeService.userCard$.pipe(
      mergeMap((existingUserCard) =>
        existingUserCard
          ? of(existingUserCard)
          : this.http.get<UserCard>(`${this.baseUrl}v1/users/user-card`).pipe(
              tap((userCard) => this.storeService.setUserCard(userCard)),
              catchError(() => {
                this.storeService.setUserCard(null);
                return of(null);
              })
            )
      )
    );
  }
}

In the getUserCard method on this service, I first check to see if the StoreService has a previously loaded UserCard instance. If it does, I just return that. However, if the StoreService does not, it will make an HTPP call to retrieve the user card from the server, store that in the StoreService, and then return the user card.

For the component that displays the user card data, I would expose properties like this as public properties on the component:

  get avatarUrl$(): Observable<string | null> {
    return this.storeService.userCard$.pipe(
      map((uc) =>
        uc?.avatarVersionKey && uc.avatarVersionKey !== 0
          ? `${this.apiBaseUrl}v1/users/${uc?.uniqueKey}/avatar?size=64&v=${uc?.avatarVersionKey}`
          : `/assets/images/avatar_small.png`
      )
    );
  }

  get userFullName$(): Observable<string | null> {
    return this.storeService.userCard$.pipe(
      map((siu) => (siu ? `${siu.givenName} ${siu.surName}` : ''))
    );
  }

Then in the HTML I need to use the async pipe to get the values out:

<span class="name">{{ userFullName$ | async }}</span>

Coding With Signals

This of course works, and it’s what we’ve been doing for years in Angular. However, now that Signals have arrived, this code can be greatly simplified. Let’s start with the Signals-based implementation of the StoreService class.

import { Injectable, computed, signal } from '@angular/core';
import { ApplicationState } from '@shared/models';
import { UserCard } from '@shared/models';

const initialState: ApplicationState = {
  userCard: null,
};

@Injectable({
  providedIn: 'root',
})
export class StoreService {
  private readonly _store = signal(initialState);
  readonly userCard = computed(() => this._store().userCard);

  setUserCard(userCard: UserCard | null) {
    this._store.update((s) => ({ ...s, userCard: userCard }));
  }
}

So far, it’s not a ton smaller or simplified from the RxJS version. Instead of a BehaviorSubject instance, I’m using a signal. The initial state is still being passed in to initialize the signal. I then define the userCard value to be a computed value. This creates a new signal, based on the _store signal in this case, that will automatically notify all of its listeners whenever the _store signal is updated, and return just the UserCard instance.

When calling setUserCard, I don’t need to call a next$ method. Calling next$ is an RxJS thing, and at least for me, it’s counter-intuitive. You have to remember that Observable is a stream of events and then next$ makes sense. However, with signals, I’m calling update, which feels more natural. The update method passes the current value of the signal to an arrow function, which I’m then spreading into a new object, and replacing the userCard value with the new UserCard. Currently, my state ONLY has the UserCard field, but as it starts to expand to hold other global state, then this becomes more useful.

The real “Oh…” moment for the cleanliness of the code for me comes in the new implementation of the UserCardService class:

import { Inject, Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { catchError, Observable, of, tap } from 'rxjs';
import { StoreService } from '@shared/services';
import { UserCard } from '@shared/models';

@Injectable({
  providedIn: 'root',
})
export class UserCardService {
  constructor(
    private http: HttpClient,
    private storeService: StoreService,
    @Inject('API_BASE_URL') private baseUrl: string
  ) {}

  getUserCard(): Observable<UserCard | null> {
    const uc = this.storeService.userCard();
    if (uc) return of(uc);

    return this.http.get<UserCard>(`${this.baseUrl}v1/users/user-card`).pipe(
      tap((userCard) => this.storeService.setUserCard(userCard)),
      catchError(() => {
        this.storeService.setUserCard(null);
        return of(null);
      })
    );
  }
}

The getUserCard method still returns an Observable, as the resolver consuming it wants an observable. However, the implementation is much easier to understand in my opinion. I can execute the userCard method off the StoreService to get the current user card if there is one, and because it’s just a method, not an RxJS Observable, I can just return it straight away if I already have it; no need for mergeMap. I then call the HTTP endpoint like before, and add the user card to the StoreService.

The component fields are also greatly simplified (it’s really nice not having to use the RxJS pipe function):

  avatarUrl = computed(() => {
    const uc = this.storeService.userCard();
    return uc?.avatarVersionKey && uc.avatarVersionKey !== 0
      ? `${this.apiBaseUrl}v1/users/${uc?.uniqueKey}/avatar?size=64&v=${uc?.avatarVersionKey}`
      : `/assets/images/avatar_small.png`;
  });
  userFullName = computed(() => {
    const uc = this.storeService.userCard();
    return uc ? `${uc.givenName} ${uc.surName}` : '';
  });

And now, in the HTML, we no longer need the async pipe. Instead, since each of these properties are signals, we access them like methods in the HTML:

<span class="name">{{ userFullName() }}</span>

Final Thoughts

I really like the new Signals API, and am looking forward to seeing where else the Angular team takes it. Will the HttpClient class eventually use Signals (maybe via a new class called HttpSignalsClient to maintain backward compatibility)? Will there be new constructs for our HTML templates that are Signals aware? Only time will tell. But so far, I really like what I’m seeing.

AWS Certified Developer – Associate

Jamie Nordmeyer — Sat, 13 May 2023 21:10:45 +0000

And that’s two down! Last September (2022), I received my AWS Certified Solutions Architect – Associate certification. This last Wednesday, (5/10/2023), I received my AWS Certified Developer – Associate certification. Humorously, I thought that this exam was actually harder than the Solutions Architect exam… yet I scored higher on this exam than the first one. I’m guessing that it’s because going into the Developer exam, I already had the experience, and knew what to expect, whereas my exam for the Solutions Architect certification was the first AWS exam that I’d ever taken. Alas. It’s out of the way now.

I don’t currently care about getting any additional certifications at this point. So, I have a good 2 years or so before I need to start worrying about studying again. Woot!

Unit Testing a Custom Angular Title Strategy

Jamie Nordmeyer — Sun, 05 Mar 2023 21:37:34 +0000

I’ve been trying to figure this out for a while but couldn’t find any good resources online on how to unit test a custom Angular Title Strategy (the TitleStrategy abstract base class was introduced in Angular 14). As a result, I left it largely untested in my project for a while. Fortunately, the implementation is simple, but I still felt “naked” not having it tested. I finally managed to find the time to dig through the Angular source code and found the documentation on how the Angular team themselves are doing this. You can the Github link here: angular/page_title_strategy_spec.ts at c0c7efaf7c8a53c1a6f137aac960757cc804f263 · angular/angular (github.com)

Again, the implementation for my title strategy is extremely simple:

import { Injectable } from "@angular/core";
import { Title } from "@angular/platform-browser";
import { RouterStateSnapshot, TitleStrategy } from "@angular/router";

@Injectable()
export class AppTitleStrategy extends TitleStrategy {
  constructor(private readonly title: Title) {
    super();
  }

  updateTitle(routerState: RouterStateSnapshot): void {
    const title = this.buildTitle(routerState);
    this.title.setTitle(`My Application${ !!title ? ' - ' + title : '' }`);
  }
}

All this does is set the page title to “My Application” (name changed to protect my work…), or to “My Application – Route Title” as the user navigates around the application. Simple. But how do I test it? Trying to mock up the RouterStateSnapshot wasn’t getting me anywhere.

After digging through the Github site for Angular itself, I realized that the trick was to NOT try mocking the RouterStateSnapshop, but instead, get a reference to the injected Router and Document instances, emulate a routing event, then check the document title. To do this, you need to pass the result of both the providerLocationMocks and providerRouter methods from the @angular/common/testing and @angular/router modules respectively during the configureTestingModulecall, then in each test, call router.resetConfig to emulate a route event. Here is my testing implementation:

import { fakeAsync, TestBed, tick } from '@angular/core/testing';
import { provideLocationMocks } from '@angular/common/testing';
import { provideRouter, Router, TitleStrategy } from '@angular/router';
import { DOCUMENT } from '@angular/common';
import { Component } from '@angular/core';
import { AppTitleStrategy } from './app-title-strategy.service';

describe('AppTitleStrategyService', () => {
  let router: Router;
  let document: Document;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        provideLocationMocks(),
        provideRouter([]),
        {
          provide: TitleStrategy,
          useClass: AppTitleStrategy,
        },
      ],
    });

    router = TestBed.inject(Router);
    document = TestBed.inject(DOCUMENT);
  });

  it('should set page title correctly when title is not provided', fakeAsync(() => {
    router.resetConfig([
      {
        path: 'home',
        component: TestComponent
      }
    ]);

    router.navigateByUrl('/home');
    tick();
    expect(document.title).toBe('My Application');
  }));

  it('should set page title correctly when title is empty string', fakeAsync(() => {
    router.resetConfig([
      {
        path: 'home',
        title: '',
        component: TestComponent
      }
    ]);

    router.navigateByUrl('/home');
    tick();
    expect(document.title).toBe('My Application');
  }));

  it('should set page title correctly when title is provided', fakeAsync(() => {
    router.resetConfig([
      {
        path: 'home',
        title: 'Home',
        component: TestComponent
      }
    ]);

    router.navigateByUrl('/home');
    tick();
    expect(document.title).toBe('My Application - Home');
  }));
});

@Component({template: ''})
export class TestComponent {
}

Little WSL Things

Jamie Nordmeyer — Tue, 27 Sep 2022 00:23:17 +0000

I just rebuilt my personal laptop and was trying to remember how I’d set up WSL the last time so that I could develop within WSL. However, there were a couple of items that I had NOT done last time, and I was determined to figure out how to make them work this time around.

Setting up the ASP.NET Developer Certificate

First, I wanted to have a valid development certificate set up so that when I run my ASP.NET 6 API, it would show as a valid certificate in the browser. Before my rebuild, this wasn’t working; the API was working fine. However, the browser always showed the site as being insecure.

It looks like .NET 6 automatically sets up the ASP.NET developer certificate when it installs. When I ran the dotnet dev-certs commands to create the certificate, it said that the certificate already existed. And sure enough, when I navigate to /usr/local/share/ca-certificates/aspnet (I’m using the Ubuntu WSL install), I can see the https.crt and https.pfx files. However, when I launch the API and get the Swagger page, the site still shows as unsecured.

What I ended up doing is opening the Windows Certificate Manager outside of WSL and installed the certificate from there. You can open the Start Menu, then search for Manage User Certificates. Once that’s open, navigate to Trusted Root Certification Authorities / Certificates. You will then want to right-click on the Certificates node, select All Tasks from the menu, then Import.... On the screen asking you where the certificate is that you want to import, navigate to \\wsl.localhost\Ubuntu\usr\local\share\ca-certificates\aspnet, and import the https.crt file.

In my case, I had to reboot my computer at this point. I’m not sure if there’s a way to refresh everything without rebooting the machine, but whatever. This worked for me, and launching the API now shows that the site is secured.

Ensuring That the Postgres Service is Running on WSL Startup

I didn’t want to have to keep manually starting the Postgres service every time I restarted my computer, so I went looking to see if there was a way to have it launch automatically at least when I first open a WSL terminal so that it’s up and running before I type code .. I found the answer here, by Wan Zulkarnain, and give full credit to the original poster. I replicate it here for my own use, and just in case that site is ever shut down.

First, I added this code to my ~/.bashrc file:

if ! pgrep -x "postgres" >/dev/null; then
    sudo pg_ctlcluster 12 main start
    echo "postgres service started using: sudo pg_ctlcluster 12 main start"
fi

I then created an sudoers file called skip_sudo_pg to make it so I didn’t need to enter the password on each start-up of WSL. In that file, I added the following one-liner:

%sudo ALL=(ALL) NOPASSWD:/usr/bin/pg_ctlcluster

After stopping WSL and reopening a new terminal window, it successfully started up Postgres for me without me needing to manually do it.

It’s the little things that you come to appreciate…

AWS Certified Solution Architect – Associate

Jamie Nordmeyer — Sat, 17 Sep 2022 00:19:06 +0000

Woot! This last Wednesday, September 14th, 2022, I finally picked up the first of two AWS certifications that I plan on getting, which is the Certified Solution Architect – Associate certification. It was a fairly difficult 2-hour exam. I know the material pretty well, but for anyone that has taken the SAT tests here in the U.S., the questions were very similar to those on an SAT. Many of the questions would have 2 answers that were both TECHNICALLY correct, but one was, naturally, MORE correct.

For anyone studying to take this exam or any of the other AWS exams, you owe it to yourself to take AT LEAST 2 practice exams prior to taking the actual exam. Running through these practice exams ABSOLUTELY helped me prepare for the real thing. Even then, I honestly wasn’t completely prepared. There were a couple questions that were about topics that my training material did not cover, and as much as I hate to admit to it, I had to make an educated guess on. So definitely… take those practice exams!

Next up for me will be 2 or 3 weeks of a break from studying, then moving on to studying for the Certified Developer – Associate exam. The recommendation that I’ve heard from both my training site and other folks that already have these certifications is to get one shortly after the other since there is a lot of overlap. I’ll target spring of 2023 for getting the Developer cert.

Whaddaya Mean “System.Object” Is Not Defined?!?

Jamie Nordmeyer — Mon, 01 Aug 2022 03:25:44 +0000

Every once in a blue moon or two, Visual Studio can get itself into a bizarre state where it’s not resolving the most basic types, like System.Object. You’ve confirmed that you’re referencing the latest version of .NET or .NET Core, you’ve cleaned and rebuilt your solution, and you’ve even rebooted your computer… all to no avail. What gives?!? Visual Studio ends up looking something like this:

Wait… what? “Predefined type ‘System.Object’ is not defined or imported”?!? This is purely a designer thing. If you try to build and/or run the solution, everything works (so long as you don’t have any genuine compiler errors, naturally…)

Well, I’m not entirely sure what is getting copied into the obj and/or bin folders that would specifically cause this, but when you do a Clean (either with dotnet clean, or via the Clean Solution menu command), there are things that aren’t removed that are apparently causing this issue. If someone knows exactly what is doing this, I’d love to know! Either way, the fix is to delete both the obj and bin folders for each project in the solution that is affected by this issue.

Once you do that, you’ll notice that they get dropped back in almost immediately IF you have the solution open in Visual Studio when you delete them. Once the new obj and bin folders are created, Visual Studio should visually clean up, and the System.Object errors will go away. Woot!

Just one of many of Visual Studio’s idiosyncrasies…

Enable Access to http://localhost For Development

Jamie Nordmeyer — Tue, 24 May 2022 03:14:15 +0000

I will forget this if I don’t get it written down, and I’m hoping that someone else will find this useful as well. If you’re having trouble accessing http://localhost from your development machine (for instance, http://locahost:4200 when starting an Angular application), you can do the following, at least for the Edge and Chrome browsers.

Open your Edge or Chrome browser, and go to edge://net-internals/#hsts or chrome://net-internals/#hsts, as applicable. At the very bottom (at least at the time of this writing), you’ll find a section called Delete domain security policies. Here, enter localhost into the Domain box, then click on the Delete button. You should now be able to access localhost from http on your development machine.

The Single Data Pipeline Pattern

Jamie Nordmeyer — Sun, 24 Apr 2022 21:18:15 +0000

In a previous post, I talked about the Clean Architecture Pattern, and I presented a .NET 6 solution template that can be used to bootstrap a .NET 6 API solution using this beautiful pattern. One of the patterns used in this template, if you opt into Entity Framework with the -includeEF parameter, is what I’m calling the Single Data Pipeline Pattern. I’m not sure if there’s an official name for this pattern, as I couldn’t find one when I went looking for it, so I’ll call it this until someone corrects me.

I’m a huge fan of sticking as much as possible to the SOLID Programming Principles when you can. This includes the S part of solid, or Single Responsibility Principle. The Single Data Pipeline Pattern, unlike the more traditional repository pattern, strives to ensure that each class in the pattern is only responsible for one and one only data pipeline to the database. It’s not concerned with the full CRUD for an entity. It cares only about reading a single form of the data. Or only about updating it. Or deleting it. But never a combination. This keeps these classes modular, and also satisfies the O of SOLID, or the Open/Closed Principle.

As an example, if I want to get a user’s avatar from the application, I might have an interface and implementation that looks like this:

// Interface definition
public interface IGetUserAvatarDataService
{
    Task<StoredFile?> ExecuteAsync(Guid userUniqueKey, CancellationToken cancellationToken = default);
}

// Implementation
public class GetUserAvatarDataService : IGetUserAvatarDataService
{
    private readonly IApplicationDbContext _dbContext;

    public GetUserAvatarDataService(IApplicationDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task<StoredFile?> ExecuteAsync(Guid userUniqueKey, CancellationToken cancellationToken = default)
    {
        return await _dbContext.Users
            .Include(x => x.AvatarStoredFile)
            .Where(x => x.UniqueKey == userUniqueKey)
            .Select(x => x.AvatarStoredFile)
            .FirstOrDefaultAsync(cancellationToken);
    }
}

The data service, by convention, exposes an ExecuteAsync method, which is the services ONLY public method. Note that this class has no ability to update or delete the user’s avatar. It only knows how to retrieve it. If my consuming code needs to also do some other work in the DB aside from retrieving the user’s avatar, then it would inject a data service for each of those additional operations as well.

For example, the endpoint for deleting a user’s avatar might look something like this:

public class DeleteUserAvatarCommand : EndpointBaseAsync
    .WithRequest<DeleteUserAvatarViewModel>
    .WithActionResult
{
    private readonly IRequestValidator<DeleteUserAvatarViewModel> _requestValidator;
    private readonly IGetUserWithAvatarDataService _getUserWithAvatarDataService;
    private readonly IDeleteUserAvatarDataService _deleteUserAvatarDataService;
    private readonly IFileService _fileService;

    public DeleteUserAvatarCommand(
        IRequestValidator<DeleteUserAvatarViewModel> requestValidator,
        IGetUserWithAvatarDataService getUserWithAvatarDataService,
        IDeleteUserAvatarDataService deleteUserAvatarDataService,
        IFileService fileService)
    {
        _requestValidator = requestValidator;
        _getUserWithAvatarDataService = getUserWithAvatarDataService;
        _deleteUserAvatarDataService = deleteUserAvatarDataService;
        _fileService = fileService;
    }

    [HttpDelete("api/v{version:apiVersion}/user/{uniqueKey:guid}/avatar")]
    [Authorize]
    public override async Task<ActionResult> HandleAsync([FromRoute] DeleteUserAvatarViewModel request, CancellationToken cancellationToken = default)
    {
        var validationErrors = _requestValidator.ValidateRequest(request);
        if (validationErrors.Any())
            return UnprocessableEntity(validationErrors.ToArray());

        var user = await _getUserWithAvatarDataService.ExecuteAsync(request.UniqueKey, cancellationToken);
        if (user is null)
            return NotFound();

        var fileUniqueKey = user.AvatarStoredFile?.UniqueKey;
        await _deleteUserAvatarDataService.ExecuteAsync(user, cancellationToken);
        _fileService.DeleteAvatarByKey(fileUniqueKey);

        return NoContent();
    }
}

Notice that this endpoint uses TWO data services to do is work; one to get the user’s record along with their avatar, and another to affect the avatars deletion. The individual calls to the database are not controlled from the same class as a repository might be. Each is independently injected and maintained. They’re also easy to mock when unit testing the classes that consume the endpoints.

Now that said, a data service using the Single Data Pipeline Pattern CAN interact with the DB more than once, if necessary, inside the ExecuteAsync method. The key is that these operations be part of the same data flow. For example, here’s the ExecuteAsync method on the DeleteUserAvatarDataService:

public async ValueTask ExecuteAsync(ApplicationUser user, CancellationToken cancellationToken = default)
{
    if (user?.AvatarStoredFile is not null)
    {
        _dbContext.StoredFiles.Remove(user.AvatarStoredFile);
        user.AvatarStoredFile = null;

        await _dbContext.SaveChangesAsync(cancellationToken);
    }
}

There’s actually TWO distinct database operations going on in this code. When the _dbContext.SaveChangesAsync method is called, it will first issue a DELETE statement to remove the StoredFile record (metadata for the avatar, or any other file that’s been uploaded by the user in my application), followed by an UPDATE statement on the User record (to set the AvatarStoredFileId column, which the AvatarStoredFile property is tied to via foreign key, to null).

As a side note, the reason that I use the naming scheme for these data services like I do is to allow me to create some bootstrapping code that will automatically add them to the dependency injection container at startup. This code exists in the .NET 6 solution template referenced at the beginning of this post. Each of my data service contracts will be called ISomethingDataService, and its implementation class will be called SomethingDataService. Then in my application start up, I can use reflection to pull them all into the DI container:

private static readonly Regex InterfacePattern = new Regex("I(?:.+)DataService", RegexOptions.Compiled);
// ...
(from c in typeof(Application.DependencyInjection).Assembly.GetTypes()
 where c.IsInterface && InterfacePattern.IsMatch(c.Name)
 from i in typeof(Infrastructure.DependencyInjection).Assembly.GetTypes()
 where c.IsAssignableFrom(i)
 select new
 {
     Contract = c,
     Implementation = i
 }).ToList()
 .ForEach(x => services.AddScoped(x.Contract, x.Implementation));

Wait, .NET is HOW old?!?

Jamie Nordmeyer — Sun, 13 Feb 2022 15:32:12 +0000

Wow, the time has really flown by, hasn’t it?!? Today marks the 20th anniversary of .NET! Released on February 13th, 2002, .NET has been through many iterations and changes over its lifetime. Originally released as a Windows only framework, it has been responsible for the careers for millions of developers around the world (including mine).

For those interested in the history full history of .NET, Richard Campbell has done a number of fantastic presentations on the subject. He’s interviewed a ton of people from Microsoft and the open-source community to compile this information, and at some point in the hopefully not too distant future, will be releasing what I suspect will be an AMAZING book on the subject. The following video is 4 years old, but it’s one that I’ve watched a couple times, and Richard does a great job of going over the history up to that point.

My personal history with .NET starts way back even before the 1.0 release in February of 2002. The company I worked for at the time was primarily working with a combination of Visual Basic 6, Excel VBA, and CLASSIC ASP based web applications. Microsoft released a beta of the .NET Framework along with their brand new “C based” language called C#.

I remember actually being quite frustrated with the beta! When the beta shipped, there was no form of Visual Studio that supported it yet. Visual Studio existed, but it was primarily an IDE for Visual C++. So to compile the beta bits of C#, you had to use the CSC compiler directly via the csc.exe command. I also recall that using statements had not been added to the language yet, so any class you used had to be fully qualified, meaning you were typing a LOT of characters.

Fortunately, the platform has matured exponentially over its 20 years of life and is now used by companies large and small to run their businesses with, with millions of developers working for those companies as .NET software developers, engineers, and architects. Today, it runs on everything from massive server farms down to the tiniest of computing devices like watches and embedded microcontrollers.

As I said, the platform has matured exponentially over the years. When .NET 1.0 released, it shipped without one of the things that I loved from the C++ world; generics. At the time of 1.0, if you wanted to create a strongly typed list of integers, you’d have to implement the IList interface. Completely. If you also wanted a strongly typed list of strings, you’d implement the IList interface again, this time for strings. When .NET 2 released with support for generics, it rocked the community with how much simpler these sorts of things were.

.NET 3 added support for several new technologies that were designed to update how Windows developers wrote code not only on Windows, but also how we communicated with the web. WPF (Windows Presentation Foundation) allowed us to use an XML based syntax for creating Windows applications and was eventually adopted into the creation of Visual Studio itself. WCF (Windows Communication Foundation) allowed services to communicate with one another using Simple Object Access Protocol, or SOAP, giving us a contractual communication channel for Service Oriented Architecture systems. SOAP is widely frowned upon today with newer architectures and technologies like REST and gRPC replacing it, but it was the way we did things in those days.

Then came .NET 3.5, and the release of LINQ, or Language Integrated Query. LINQ revolutionized how .NET developers worked, allowing us to treat enumerable collections of data in a more functional way than before, and to literally write SQL-like syntax in our code to filter this data. Along with the release of LINQ came the first release of Entity Framework, and whether you love or hate EF, it absolutely changed the development landscape for .NET programming.

.NET 4 and 4.5 set the stage for simpler asynchronous programming and working with data types not necessarily known at compile time by bringing in the Task Parallel Library and dynamics, respectively. The former made it much easier to work with asynchronous programming, with the latter bringing us finally to the methodology that most of us are familiar with today, the async/await pattern. This pattern proved so successful that it has seen itself move into other languages as well, such as JavaScript/TypeScript.

At this point, Microsoft moves into cross-platform and open-source support in .NET in earnest with .NET Core. Giving us the ability to develop and run our code bases on Windows, Linux, and Mac was a HUGE leap ahead for .NET and C#. Naturally, some Windows specific things did have to be left behind with the .NET Framework, such as GDI (System.Drawing), Windows Forms, and so forth. But the majority of .NET was able to transition to .NET Core, and this is how we get to write code that runs on everything from massive server farms to the smart watch on your wrist.

Starting with .NET 5, Microsoft of course “merged” their support of .NET into a single runtime. They dropped the Core name (though retained it for ASP.NET Core), and while they will still support the Windows only .NET Framework with security fixes, they are no longer actively working on it, focusing their efforts on .NET 5 and on. They’ve reintroduced Windows Forms development (naturally Windows only, though) to sit on top of .NET 5+, and will be releasing Maui at some point in the future to support cross-platform desktop development with a XAML based programming model.

It truly is a fantastic time to be a .NET software professional or hobbyist!!! Despite the platform being 20 years old, it is still going incredibly strong. It enjoys a thriving community of both corporate and open-source supporters, and with a promised annual release cycle, continues to be added to. Microsoft pays attention to feedback on Github, and has even merged in pull requests from the community that have been deployed as part of the official product.

As someone that’s built their entire career on .NET and C#, all I can say is Happy Birthday, .NET and C#!!! And thank you!

.NET Global CLI’s

Jamie Nordmeyer — Sun, 26 Dec 2021 05:24:33 +0000

UPDATE: This project has now been upgraded to .NET 8. I’ve blogged about it here.

Merry Christmas and Happy Holidays to everyone!!! I know that it’s Christmas day, but as the day winds down, and I sit here after a fabulous Chrismas dinner, I have some time to kill, so I thought I’d get out this short post. :)

The other day I was watching this video from the talented Nick Chapsas:

I’ve created CLI applications before with .NET Core as well as .NET Framework, but I’ve never thought about doing so using the .NET tooling infrastructure. This is actually a really nice way to package up a CLI as a Nuget package, distribute it, and install it globally on your system so that instead of having to use dotnet run, you can just use a chosen name for the CLI without having to compile it to a native application on each operating system. In this post, I’m going to cover how I used the tools shown by Nick to create an extremely simple CLI for generating GUID’s.

I created a new .NET 6 console application with the dotnet new console command. To this project, I added a reference to the CommandLineParser Nuget package. When this project is built, it creates a Nuget package, so I included the following PropertyGroup section to the .csproj file to define the Nuget attriutes displayed with the package:

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFramework>net6.0</TargetFramework>
  <ImplicitUsings>enable</ImplicitUsings>
  <Nullable>enable</Nullable>
  <PackAsTool>true</PackAsTool>
  <ToolCommandName>guid</ToolCommandName>
  <PackageOutputPath>./dist</PackageOutputPath>
  <DefaultNamespace>StaticSphere.Cli.Guid</DefaultNamespace>
</PropertyGroup>
<PropertyGroup>
  <PackageVersion>1.0.0</PackageVersion>
  <PackageId>StaticSphere.Cli.Guid</PackageId>
  <Title>GUID Command Line Interface</Title>
  <Company>StaticSphere</Company>
  <Authors>Jamie Nordmeyer</Authors>
  <Copyright>Jamie Nordmeyer © 2021</Copyright>
  <Description>A global .NET based tool for generating GUID's</Description>
  <PackageTags>c#;core;cli</PackageTags>
  <PackageCopyright>Jamie Nordmeyer © 2021</PackageCopyright>
  <PackageProjectUrl>https://github.com/StaticSphere/guid-cli</PackageProjectUrl>
  <PackageLicenseExpression>MIT</PackageLicenseExpression>
  <RepositoryType>git</RepositoryType>
  <RepositoryUrl>https://github.com/StaticSphere/guid-cli</RepositoryUrl>
</PropertyGroup>

Next, I created a class called CommandLineOptions that tells my application how to display the command line parameters that I want the applications user to optionally provide. When the CLI is run with the --help parameter, it uses the settings specified in this class to show the user the parameters that they can define:

using CommandLine;

public class CommandLineOptions
{
    [Option('l', "lowercase", Required = false, HelpText = "If specified, the guid is created with lowercase letters")]
    public bool LowerCase { get; set; }

    [Option('n', "nodashes", Required = false, HelpText = "If specified, the guid is created with no dashes")]
    public bool NoDashes { get; set; }
}

I really like how the CommandLineParser project wraps these options, as it’s extremely easy to specify the options that you want to provide, and to read the code and determine how to use the various parameters are being used.

Finally, the Program.cs file itself is using C# pattern matching syntax, along with the provided options if defined by the user, to create a GUID with the proper output format:

using CommandLine;

Parser
    .Default
    .ParseArguments<CommandLineOptions>(Environment.GetCommandLineArgs())
    .WithParsed(o =>
    {
        var guid = o switch
        {
            { LowerCase: false, NoDashes: false } => Guid.NewGuid().ToString().ToUpper(),
            { LowerCase: false, NoDashes: true } => Guid.NewGuid().ToString("N").ToUpper(),
            { LowerCase: true, NoDashes: false } => Guid.NewGuid().ToString(),
            { LowerCase: true, NoDashes: true } => Guid.NewGuid().ToString("N")
        };

        Console.WriteLine(guid);
    });

You can still run this application without installing it:

cd <<source location>>
dotnet run
dotnet run --lowercase
dotnet run -n
dotnet run -ln

But if you want to install it as a global tool, you’ll need to pack it and install it:

cd <<source location>>
dotnet pack # This creates a Nuget package under the ./dist folder
dotnet tool install --global --add-source ./dist StaticSphere.Cli.Guid

But of course, you can install it from Nuget.org if you’d rather have the already compiled version:

dotnet tool install --global StaticSphere.Cli.Guid

You can find the source on GitHub here, and the Nuget package, ready to be installed, via the above command line, here.

Clean Architecture Solution Template

Jamie Nordmeyer — Thu, 25 Nov 2021 22:55:17 +0000

UPDATE: This project has now been upgraded to .NET 8. I’ve blogged about it here.

I’ve become a huge fan of the Clean Architecture pattern when working on .NET API’s. I won’t go into a ton of detail here, as there are a lot of great resources out there on the subject already, including from the person that I first learned it from, Jason Taylor. If you’re unfamiliar with this pattern, do yourself a favor and check out this presentation by Jason from the GOTO 2019 conference:

But at the 10,000 foot level, an API project using the Clean Architecture pattern has 4 separate projects (along with the necessary unit testing projects):

Domain – This project is meant to hold the domain entities of the application. The classes in this project map to the data tables or records in whatever data store the application is configured to use.
Application – This project contains the business logic and rules that make the application as a whole run as it’s supposed to. It directly references the Domain project, but no other projects within the solution.
Infrastructure – This project contains the implementation of any logic that needs to communicate with outside entities, such as a database, the file system, other HTTP API’s, and so forth. It references the Application project to gain access to application contracts that it will then implement for accessing the aforementioned external entities.
Api – This is the front-end of the application, and provides the start-up code and the API endpoint entry points.

Solution Template Nuget Package

I’ve created a Nuget package called StaticSphere.CleanArchitecture.Api, and published it to Nuget.org. You can install it using the following command:

dotnet new --install StaticSphere.CleanArchitecture.Api

Once installed, you can create a new solution by running the following command:

dotnet new clean-arch <<parameters>>

When executed, you’ll get a full .NET 6 ASP.NET API solution that contains the following folder structure (assuming you named to the solution HelloWorld):

src
- HelloWorld.Api
- HelloWorld.Application
- HelloWorld.Domain
- HelloWorld.Infrastructure
tests
- HelloWorld.Api.Tests
- HelloWorld.Application.Tests
- HelloWorld.Infrastructure.Tests

The projects are all .NET 6 applications with nullable references types and implicit usings enabled. The unit testing projects use Xunit out of the box. There are also support files such as .gitignore, .editorconfig, etc.

There are parameters that can be passed to the dotnet new command that alter the solution that is created:

–includeTests – Determines if the test projects should be included or not. Default value: true
–skipRestore – If specified, skips the automatic restore of the project on create. Default value: false
–useStartup – Determines if the API project should use Startup.cs instead of the newer Minimal API style Program.cs file. Default value: false
–includeEF – If set, the created solution will include Entity Framework Core, and will be configured to use the specified provider (only these providers are currently supported)
- postgres – Adds Postgres Entity Framework configuration
- sqlserver – Adds SQL Server Entity Framework configuration

Open Source

The Nuget package that contains the solution template is completely free and open source, and is MIT licensed. The Nuget package can be found here, and the source code for the template can be found here. If you have any suggestions, or would like to contribute to the template, please let me know!