This version includes some additional fixes via Philip Peitsch (thanks!!)

And of course, another “Thank You!” to Catchco and Robert “Stay Off My Lawn!” Simmons for their work on Autofac support.

SpecsFor 6 Final Released

SpecsFor 6 has been hanging out in preview form for nearly 4 months! I sort of lost track of the fact that I hadn’t published the final version.

Anyway, 6 Final is now out there, which includes .NET Core support. If you want to know more about this update, check out this really old post. For the most part, this version should be compatible with your existing SpecsFor projects, sans SpecsFor<MVC>, which is heading towards retirement.

SpecsFor 7 Preview Released

That brings us to SpecsFor 7. This version takes the first steps towards making SpecsFor more flexible. Thanks to the awesome contributions of Catchco developer Robert “I’m too good for social media!” Simmons, the core of SpecsFor is now IoC container agnostic! We’re shipping two official packages now, one for StructureMap, and one for Autofac. Creating your own adapter for other frameworks is actually fairly easy. Maybe Rob will write a guest post illustrating the process. Maybe showing integration with Lamar, perhaps?

If you’d like to see another container officially supported, feel free to submit a pull request!

We did remove several things from the v7 release. A lot of it was cruft that the project has picked up over the better part of a decade. Some features will probably be added back once I realize that I actually needed them…. ?

If you find something missing, drop an issue here on Github, and I’ll see about adding it back before v7 final is released.

Installing SpecsFor 7

There are now 4 SpecsFor packages you can choose from:

• SpecsFor.Core – This is the heart of SpecsFor. You shouldn’t install this directly unless you plan to write an adapter for a different IoC container.
• SpecsFor.StructureMap – If you want to use StructureMap’s automocking container, install this. If you’re using SpecsFor today, this package is what you want.
• SpecsFor.Autofac – This is the package you want if your main project uses Autofac.
• SpecsFor – This is now just a meta package for SpecsFor.StructureMap. It exists just to make it easier to upgrade. At some point this will be the “kitchen sink” package that pulls in all the test helpers and conventions as the core of SpecsFor is refactored further..

No matter which package you install, you will still derive from the base SpecsFor<T> class, just like you do today. The only thing that changes is which using statement you add:

using Moq;
using NUnit.Framework;
using Should;
// Just "use" the namespace for whichever package you installed! 
using SpecsFor.StructureMap;

namespace SMTests
{
    public class WidgetSpecs
    {
        [TestFixture]
        public class when_starting_a_widget : SpecsFor<Widget>
        {
            protected override void When()
            {
                SUT.Start();
            }

            [Test]
            public void then_it_sets_the_status_to_running()
            {
                SUT.IsRunning.ShouldBeTrue();
            }

            [Test]
            public void then_it_raises_an_event()
            {
                GetMockFor<IEvents>()
                    .Verify(x => x.Publish(It.IsAny<WidgetStarted>()));
            }
        }
    }
}

There is one issue with the current beta release: you must manually install both the Microsoft.NET.Test.Sdk and NUnit3TestAdapter packages. If you don’t, the test runner won’t see your specs. I’m trying to find a way to bake this in to SpecsFor, but I’m coming up empty. Help is appreciated!

What’s Next?

I would like to get the whole Microsoft.NET.Test.Sdk dependency issue squared away, but I don’t know if that’s possible. .NET Core is still a mess in this area.

After that, the original roadmap for SpecsFor vNext still applies. I would love to get things broken up where both xUnit and NUnit work.

If no major issues are reported, I plan to release v7 final early next week. Someone please remind me if I forget. ?

Thanks again to Catchco and Robert “what’s a twitter?” Simmons. This release wouldn’t have happened without your contributions!

slugify is a handy npm package to convert a string to a “slug”. Think “Some Document Title” to “some-document-title”! I actually created a cmdlet using this for normalizing my blog post titles, but that’s a post for another day.

I spend about 75% of my day in Visual Studio Code, and I still didn’t know about many of the things in this list.

Are you remembering to unsubscribe your subscriptions in Angular? Netanel Basal took a stab at an automatic approach. Sadly it isn’t completely automatic, but it’s close!

I’m not usually a fan of abstraction for abstraction’s sake, but observable services in Angular can be quite useful, and easy to build.

The Angular CDK is a great library. I plan to blog about some of the things I’m doing with it soon. In the meantime, check out how to build an expansion panel with it.

I’m still getting up to speed on Angular Animations. This post at AlligatorIO is a bit dated, but it still helped me a lot.

Another good one from AlligatorIO: Angular has a built-in abstraction for DOM manipulation.

I’ve been using Moment.js for a long time, yet I didn’t realize how fully you could customize it.

I love LINQ. It’s one of my favorite C# features. I spend quite a bit of time writing JavaScript though. Fortunately, many LINQ operations translate nicely to built-in JavaScript functions. Array.some can be used in JavaScript in much the same way you might use Any in C#. Here’s more about that function.

“Scope” matters when dealing with variables in Angular templates. I’ve been burned by this before.

Ever wanted to implement two-way bindings in Angular? Here’s how they actually work.

I’ve been working with various 3rd party systems and their webhooks. Both NGrok and localtunnel allow you to spin up your app locally, then get a public-facing URL that points to your app. This was invaluable, and works great with ASP.NET Core running locally.

NLog has been my go-to logging solution for years. Getting it up and running in ASP.NET Core 2 is actually very easy.

Want to show an avatar for your users, but don’t want to manage the avatars yourself? Give an Email address to unavatar, and it will look across various social services to find a profile picture for you.

if-else conditions are a new thing in Angular 4+. I somehow overlooked them until recently, but they do indeed help you write cleaner templates in some cases.

Lesson learned from Stack Overflow: if you want to accept form parameters in ASP.NET Core, use the FromForm attribute!

Need to parse a string containing a “full name” into first, middle, and last reliably? It isn’t as easy as just splitting on whitespace. Check out NameParserSharp instead!

If you’re using just about any Angular libray, you’ve probably seen the forRoot pattern. Here’s a good write-up if you’re curious what is actually going on, or if you want to know how you can use the pattern when building your own modules.

I like the idea of Parcel because it (mostly) Just Works, even with Vue SFC. Angular support doesn’t seem to be all the way there yet, but it’s still worth keeping an eye on.

There’s so much you can do with Microsoft Azure these days that it’s easy to miss out on cool features and capabilities. Michael Crump’s Azure Tips and Tricks series is a great way to learn about all the awesome little things Azure can do!

I released Build Your Own Application Framework with ASP.NET MVC 5 back in 2014. I never expected that course to take off the way it did, and it remains my most popular Pluralsight course to date.

Unfortunately, a lot has changed in four years, and a lot of the content in the course has not aged well. I’m constantly asked, “Are you going to make an updated application framework course??” After a couple of false-starts, I can finally answer that question with “Yes!”

But this course is going to be different.

First, I’m going to be self-publishing this course. That does not mean I’m finished making courses for Pluralsight! I just wanted to try an alternate publishing medium this time.

Second, my goal is to cover only what I consider absolutely essential, and only for ASP.NET Core. That means no Angular, no Aurelia, just server-side .NET code. Assuming there is sufficient interest, I’d like to do an app framework course that covers topics for Angular at a later date.

Third, I want to create this course out in the open. I want feedback from the community early and often.

To that end, here are the major topics I’m planning on covering in this course. Please drop me a note either in the comments below or via twitter (@matthoneycutt) and let me know what you think. Are there things I’m not covering that you would like to see? Things I’m covering that you don’t care about? I want to hear from you!

Overview

The course will cover several tools and techniques, including:

• Lamar
• AutoMapper
• MediatR
• Entity Framework Core

Turbo-Charging ASP.NET Core IoC with Lamar

Learn about the benefits of Lamar over the built-in Microsoft DI container. You’ll see how to add Lamar to an existing project, how to organize things into registries, and how to leverage type scanning and conventions to make your code easier to maintain while opening up new patterns that can help you solve problems more efficiently.

Streamlining Your Controllers

Out of the box, ASP.NET Core controllers can quickly become a mess of attributes, magic strings, validation, data access, and business logic. See how a few simple changes can help you organize your code better, eliminate attribute soup, tame magic strings, and eliminate tedious property assignments.

Tame Your Data Access and Business Logic

Continuing on, you’ll see how to reduce down the amount of code that lives in your controllers to something more manageable, how to eliminate architecture layers that aren’t providing value, and how to push cross-cutting concerns out of your controllers.

Your Feedback Is Important!

So what do you think? If this “Essentials” course is something you are interested in, please let me know what you think of the outline.

But what do we do when we need to share configuration data between Angular and ASP.NET Core? Here is one option for you.

Credit Where Credit is Due

I actually started writing this post back at the beginning of May, but I never finished it. In the time since I started working on this, I noticed that Eric Anderson tackled the very same problem on his blog. His solution is similar to mine, especially on the client-side of things (nice job, Eric!). But I tackled things a bit differently on the server-side, and I decided to finish out my post just to elaborate on a few of the concepts a bit further.

The Challenge

This post is partially in response to a question from Nigel over at my “Build Your Own App Framework” Pluralsight Course. One of the techniques I show in that course is how to pass data from ASP.NET MVC to Angular. I also show that same technique here on my blog, so feel free to check it out if you’re curious.

The pattern was more applicable in the AngularJS/ASP.NET MVC (non-Core) days, because AngularJS could be used to create “Silo SPAs” quite easily, and it had no built-in configuration system to speak of.

Neither of those things are true with ASP.NET Core and Angular 2+. Angular no longer lends itself to the “Silo SPA” approach, and it does have a configuration system built in.

But that doesn’t mean the idea of passing configuration between the two systems is irrelevant.

There’s still some configuration data that might make sense to have shared between both Angular and your ASP.NET Core application. Examples of things that might make sense to share both server and client-side are things like public keys, or non-sensitive tokens, or, in a multi-tenant application, information about the current tenant.

So how can we share config? How can we specify config settings exactly once, and leverage them in both places?

The Solution

The simplest solution I’ve come up with is this: expose configuration data from ASP.NET Core via an API endpoint, and have Angular make a request to this endpoint during application startup.

The endpoint could return whatever makes sense. A simple JSON object will probably suffice in many cases:

{
    "setting1": "value1",
    "setting2": "value2",
    //And so on...
}

That sounds trivial, but there are a couple of gotchas, as we’ll soon see!

Defining the API Endpoint

Let’s go ahead and start by making an API endpoint to return config data:

    [ApiController, Route("api/config")]
    public class ConfigController : Controller
    {
        [HttpGet("")]
        public IActionResult Get()
        {
            
        }
    }

Easy enough so far. Now we want to grab specific config settings from our applications configuration data, and pass those down. I emphasize specific, because your configuration probably has lots of things you don’t want to expose like this. This is doubly true in ASP.NET Core, because by default, your config data will also contain all of your environment variables!

Remember that anything you return from your API is visible to the end user. It’s effectively in the hands of the enemy! If you return everything, you are more than likely passing sensitive information, including connection strings, and that would be a Bad Thing^TM. Be selective, and only return the minimum!

We could manually extract and pass config data, which would look like this:

public class ConfigController : Controller
{
    private readonly IConfiguration _config;

    public ConfigController(IConfiguration config)
    {
        _config = config;
    }

    [HttpGet("")]
    public IActionResult Get()
    {
        return Ok(new
        {
           //Grab whatever settings your client app needs, and pass them back!
           clientName = _config.GetSection("CustomerSettings:ClientName").Value,
           defaultPage = _config.GetSection("CustomerSettings:DefaultPage").Value
        });
    }
}

Or, if we choose to keep all of our shared config in a single section, and just pass the entire section:

public class ConfigController : Controller
{
    private readonly IConfiguration _config;

    public ConfigController(IConfiguration config)
    {
        _config = config;
    }

    [HttpGet("")]
    public IActionResult Get()
    {
        var targetSection = "customerSettings";
        //The magic happens here! 
        return Ok(_config.GetSection(targetSection)
            .AsEnumerable()
            .Where(x => x.Key != targetSection)
            // Since we are enumerating the root, 
            // each key will be prefixed with our 
            // target section, so we need to strip
            // that prefix off.
            .ToDictionary(x => x.Key.RemoveStart($"{targetSection}:"), x => x.Value));
    }
}

This approach has one nice benefit: if you add a new config setting, it will automatically be passed down. Of course, it’s also a bit dangerous, since if you accidentally add a sensitive setting in there, you might not realize it is being exposed to clients via the API.

There’s a bit more we could do here if we wanted. We could grab information about the current user, or in a multi-tenant application we could grab information about the current tenant. We could add caching, too, if we wanted.

Also note that while I’m using .NET Core’s IConfiguration provider, you could actually pull “config” settings from another source, too. If you store some config data in a database, you could retrieve that here, and pass it back as well.

That takes care of the ASP.NET Core side of things, so let’s take a look at the Angular-side.

Loading Configuration

So we have our config endpoint, we have our client app, it should be trivial to pull that data in… right??

Not so fast.

This is where things get a tad tricky.

Calling the endpoint is easy, but that’s an asynchronous call! Our app probably needs this data before it does anything else!

It turns out that Angular actually supports application initializers that are a perfect fit for what we’re doing here.

Let’s start by building a service that will allow us to retrieve configuration data from our API.

Creating the Configuration Provider

Let’s define a service to wrap our config data. I’m going to keep things loosely-typed, but you could define strongly-typed wrappers instead of exposing the configuration data directly:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http'

// This represents our raw config from the server.
// We could define a strongly-typed config class
// that wraps the values from the server, but for
// this simple demo, we won't bother with that.
export declare type AppConfig = { [key: string]: string };

@Injectable()
export class AppConfigProvider {

  private config: AppConfig;

  constructor(
    private httpClient: HttpClient
    ) { }

  loadConfig() {
    return this.httpClient.get<AppConfig>('api/config').toPromise().then(x => {
      this.config = x;
    });
  }

  getConfig() {
    return this.config;
  }
}

We also need to add our config provider to our application module’s providers:

// SNIP
import { AppConfigProvider } from './config/app-config-provider.service';

@NgModule({  
  // SNIP
  providers: [
    AppConfigProvider
    ],
  // SNIP
})
export class AppModule { }

Now our components (and other services!) can inject AppConfigProvider in order to have access to our AppConfig data.

Or they would be able to do that, if only someone was actually calling loadConfig first!

Hooking in to Angular’s Application Initialization

The challenge now is to make sure our loadConfig function is called before anything else happens in our app. It turns out that Angular has built-in support for scenarios just like this in the form of application initializers.

Note that app initializers are considered experimental still, so their exact implementation and behavior may change in future releases.

Over in our app.module, we can register a new app initializer like so:

// SNIP
import { NgModule, APP_INITIALIZER } from '@angular/core';
// SNIP

@NgModule({
  // SNIP
  providers: [
    AppConfigProvider,
    {
      provide: APP_INITIALIZER,
      useFactory: (appConfigProvider: AppConfigProvider) => {
         return () => appConfigProvider.loadConfig();
      },
      multi: true,
      deps: [AppConfigProvider]
    }
    ],
  // SNIP
})
export class AppModule { }

There’s actually a lot going on here, so let’s focus in a bit:

{
  provide: APP_INITIALIZER,
  useFactory: (appConfigProvider: AppConfigProvider) => {
     return () => appConfigProvider.loadConfig();
  },
  multi: true,
  deps: [AppConfigProvider]
}

See that provide? Statement? That tells Angular that we’re providing a service with APP_INITIALIZER as its injection token. This particular token is used by Angular during application initialization (surprising, I know!) Angular will take care of instantiating our service and executing it automatically.

And that useFactory part? That registers the factory that Angular will grab during app initialization. It’s a bit meta, but Angular expects our factory to be a function that returns a function. And that function we return is calling our loadConfig function.

Since that function returns a promise, Angular will pause app initialization until the promise is resolved. And that’s exactly what we want: Angular won’t finish initializing until our AppConfigProvider has loaded its configuration data.

The final two parts of our provider definition are fairly simple: multi tells Angular that it’s perfectly fine if there are multiple app initializer providers registered. The deps part tells Angular that our factory has a single dependency, AppConfigProvider, which will be passed to our factory function.

Putting It All Together…

Now that we have all the pieces in place, we should be able to inject our AppConfigProvider anywhere we need it, like in our home component:

import { Component } from '@angular/core';
import { AppConfigProvider, AppConfig } from '../config/app-config-provider.service';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
})
export class HomeComponent {
  appConfig: AppConfig;

  constructor(
    private appConfigProvider: AppConfigProvider
  ) {
    this.appConfig = appConfigProvider.getConfig();
  }
}

And at runtime, our component will receive the provider after it has already loaded the configuration data:

Wrapping Up

So that’s one approach to sharing data between ASP.NET Core and Angular. If you know of others, please feel free to share them in the comments!

Oh, and if you want the code, it is available on GitHub.

Enjoy!

Why IoT?

So if you’re a web developer, why should you care about IoT? It’s just one more thing to try and learn, right?

Well, there are actually about 2 trillion reasons: IoT, as the Internet of Things is commonly know, is predicted to enable roughly 2 TRILLION (with a T) dollars in productivity improvements by 2022. source

Security spending related to IoT alone will surpass 3 billion by 2021. source

And Microsoft is throwing money at IoT, too, to the tune of 5 billion by 2022. source

That’s why you should care about IoT: there’s going to be a tremendous amount of money spent in this area, which means new opportunities for you as a developer!

Besides the money and new opportunities, building IoT solutions is just a ton of fun. There’s something incredibly satisfying about wiring a device together, then communicating with it remotely via IoT Hub.

What You’ll Learn

My course is meant to give you a solid foundation on both the device-side and cloud-side of things. Topics you’ll learn about include:

• Azure IoT Hub itself
• Creating a (virtual) device application with .NET Core
• Sending commands and messages
• Processing messages using IoT Hub

By the end of the course, you’ll have a solid foundation for building a solution on Microsoft Azure IoT Hub.

So give it a try, and let me know what you think of this course!

Azure IoT Hub for Developers: Getting Started

The Journey to .NET Standard

“One can only slack for so long…” – Me, when I finally started work on .NET Standard support for SpecsFor

I am probably one of the worst open-source project maintainers, ever. I’ve let SpecsFor languish without .NET Standard support for far too long.

I had my reasons though. Prior to 2018, most of my production work still targeted .NET 4.7. To be perfectly honest, I didn’t even like .NET Core until 2.1. I feel like we’re just now hitting the point where it’s an actual, viable, stable solution. I’m only just now diving in to the pool all the way.

So there was that lack of motivation, but then there were also the dependencies!

SpecsFor is actually built on top of several different libraries: NUnit, Jeremy Miller’s StructureMap, kzu’s Moq, Derek Greer’s ExpectedObjects, and Eric Hexter’s Should. SpecsFor has varying degrees of dependencies on each of these libraries. You might (correctly) say it is tightly coupled to each of these projects.

This made perfect sense to me at the time. SpecsFor was originally meant to be a highly opinionated framework: you wrote specs using a specific combination of tools, in a specific way, with some glue in the middle to help make things work together nicely.

That’s an awesome idea, and it works fine… until one of those dependencies stops being maintained. That is exactly what happened to Should. In order for SpecsFor to target .NET Standard, I would have to break that dependency on Should.

That turned out to be more difficult than you might think, and in the end, I actually ended up forking Should, reworking that for .NET Standard, and shipping that as its own NuGet package, Should-DotNetStandard.

This is a temporary solution for the 6.0 release. I don’t plan to support Should-DotNetStandard for long. In fact, I don’t plan for SpecsFor to remain coupled to much of anything in the future. But we’ll get to that in a second! Let’s talk about ASP.NET MVC.

Saying Goodbye to SpecsFor.Mvc

As much as it pains me, I’m planning to retire SpecsFor.Mvc. I’ll continue to fix bugs and accept pull requests for the foreseeable future, but it will not be getting ASP.NET Core support. If you want to use it for ASP.NET MVC 5, feel free to do so! But don’t expect to see it working with ASP.NET Core.

I have my reasons for retiring this project. It was always difficult to maintain and support, but more than that, I just don’t feel that there’s much of a fit for it in ASP.NET Core. Microsoft decided to basically abandon the whole strongly-typed approach to things when they deprecated HtmlHelpers and went with TagHelpers in ASP.NET Core. Beyond even that, there’s the fact that most apps, at least the ones I work with, are built on front-end frameworks like Angular, and those frameworks have their own tools for UI testing.

So that’s that: SpecsFor.Mvc is still out there and will still work for ASP.NET MVC 5 apps. I’ll still try to fix bugs as they are found, and I’m still accepting pull requests. In fact, I’m shipping a small update today thanks to a pull request from Nick Divinci, plus a few minor improvements to the code itself.

But, unless someone wants to step in and champion the work (or pay me to champion it?), it won’t be following its sibling into the land of .NET Standard.

With that depressing bit out of the way, let’s talk about what’s next for SpecsFor!

SpecsFor vNext

My focus with the SpecsFor 6.0 release is to get things working stably as a .NET Standard package. I don’t plan to add new features to this version. I just want to get it all working, and working well, on .NET Core, .NET Full, etc.

I have very different, probably overly-ambitious, goals for SpecsFor 7.0.

For SpecsFor 7.0, I want to accomplish two contradictory goals at once: provide a solution that is flexible and can be used with the tools of your choice, and provide a highly-opinionated solution with the latest-and-greatest tooling. How can I do both of these things at once? Here’s what I’m thinking:

• SpecsFor.Core – The core “engine” of SpecsFor. No dependency on anything else, just some abstractions.
• SpecsFor.Assertions – Framework-agnostic test helpers. Things like ShouldLookLike and other common helpers would live in this package.
• SpecsFor.Web – Framework-agnostic helpers to simplify common ASP.NET Core testing scenarios.
• SpecsFor.EF – Framework-agnostic helpers to simplify common Entity Framework testing scenarios, enabling simple, easy integration testing.

Those will be the “core” packages, with as few dependencies as I can get away with in each. The idea is that you can pick and choose what you need, configure it to use whatever testing framework, mocking framework, and assertion library that you want. I hope to have packages available for common configurations, probably something like:

• SpecsFor.NUnit – Wiring to enable SpecsFor to work on top of NUnit.
• SpecsFor.XUnit – Wiring to enable SpecsFor to work on top of XUnit.
• SpecsFor.StructureMap – Configures SpecsFor to use an auto-mocking StructureMap container for creating everything (just like it does today).
• SpecsFor.SimpleInjector – Configures SpecsFor to use an auto-mocking SimpleInjector container.
• SpecsFor.Moq – Configures SpecsFor to use Moq for creating mocks.
• SpecsFor.FakeItEasy – Configures SpecsFor to use FakeItEasy for creating mocks.

You get the idea: small, modular packages, that you can mix and match to fit however you want to write your specs.

But I still plan to have a “mega” package:

• SpecsFor – The highly-opinionated kitchen sink. Built on SpecsFor.Core, wired up to use a specific testing framework, a specific set of assertions, a specific mocking library, etc.

I’m not sure exactly which tools I’ll choose for this mega package yet. I know I want to use Shouldly for its awesome exception messages. Other than that, I may end up keeping the current set of tooling. I’m also tempted by XUnit, but its approach to testing is not really compatible with SpecsFor, and I’m still not sure how I’m going to make SpecsFor work on top of it. If you think I should ditch one tool for another, let me now.

It’s going to be a lot of work, but I think that will greatly open up the places that SpecsFor can be applied. Plus it’ll be fun (I think)!

Interested in Helping?

All of that said, 7.0 is going to be a lot of work. I’d love to get some help on this. If you’re interested in championing any one of these packages, or helping with the core redesign, please contact me! And if you work for a company that is using (or interested in using) SpecsFor, and you’d like to sponsor some of the new work, let me know! ?

Getting Started

Angular 6 includes a lot of tooling improvements, so it’s worth the upgrade. And thanks to the new ng upgrade command, upgrading your Angular projects has never been easier!

We’re going to start with the “enhanced” project we made in a previous post. You can check that project out here. The steps would be mostly the same if you were to take a stock Visual Studio Angular project.

If you have a more complex Angular project and want to see how difficult it will be to upgrade, you can use the new Angular Update Guide. But be warned! There are still issues with ng update, so the update guide might not work for you.

Installing Angular 6

The first thing we need to do is install the Angular 6 CLI. You can do this globally from the command prompt of your choice:

npm i -g @angular/cli

This gives us the latest-and-greatest Angular CLI. You can verify that you have it installed by running ng -v. You should see something like this:

Upgrading Your Project’s Tooling

We have Angular 6 installed globally, but our project has its own, local copy of the CLI, and that’s still the old version! We need to upgrade that, too! There’s a bit more work we have to do first though…

I’m actually not going to do things the official way. The docs will tell you to upgrade the CLI first. I tried that, but ran into issues. I followed the workaround from this issue instead.

Before you open your Visual Studio solution, navigate to the ClientApp directory of your project using your favorite command prompt.

First, use ng update to update all of your Angular references:

ng update

Next, update rxjs to take care of a dependency issue:

ng update rxjs

Now you can use ng update to update your project’s CLI:

ng update @angular/cli

This will remove your existing .angular-cli.json file, and add a new angular.json file. It will also update a handful of other files, too.

If you have other dependencies, such as Angular Material, you will need to perform some additional steps. The Angular Update Guide should get you pointed in the right direction.

We’re getting there! Now we’re ready to turn our attention to fixing up our project’s integration with Visual Studio 2017.

Fixing the Tasks

The old Angular project template called ng serve and ng build with the extract-css option. That option is no longer valid, so we need to remove it from our npm tasks.

Open your package.json file, and change the entries in the scripts section to remove the obsolete option from both the start and build tasks. You should have something like this after the change:

{
  //snip
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "build:ssr": "npm run build -- --app=ssr --output-hashing=media",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },
  //snip
}

Now the start and build tasks should work again.

Putting it All Together

It should be safe to open everything in Visual Studio now. Task Runner Explorer should be able to run the npm start task without error, and we should be able to go ahead and run our app… You can go ahead and try it, if you want.

But me, I’m a bit skeptical… how will I know for sure that my app is actually using Angular 6?

There are a couple of ways, but here’s an easy one: I can make a small adjustment to the home view so that it displays the current Angular version.

In home.component.ts, I can import VERSION and make its full property available off of the component:

import { Component, VERSION } from '@angular/core';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
})
export class HomeComponent {

  version: string;

  constructor() {
    this.version = VERSION.full;
  }
}

Then I can display it in the view:

<h1>Hello, world!</h1>
<p>You are running Angular {{version}}!</p>
<!-- snip -->

Looks like it worked!

Get the Code

So there you have it: upgrading to Angular 6 is easy, though not quite as easy as it should be yet due to issues with ng upgrade. I’m sure those kinks will be worked out, and once they are, it will be easier than ever to stay up to date with the latest and greatest of Angular.

The code for this demo is checked in to the same Github repository that I used before. Feel free to check it out.

Did you find this post useful? Are there other topics you’d like to see me cover on this blog? Please drop me a comment below!

Breaking Change

This is a breaking change from previous versions. If you are upgrading from 4.0.0, you will need to make a small change.

Previous versions used WebActivatorEx to automatically wire things up for you, usually with no code changes on your part. That’s no longer the case with 5.0.0.

Instead, you will need to explicitly call one of HeroicAutoMapperConfigurator‘s configuration methods, like so:

    public class MvcApplication : System.Web.HttpApplication
    {
        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            HeroicAutoMapperConfigurator.LoadMapsFromAssemblyContainingTypeAndReferencedAssemblies<HomeController>();
        }
    }

But there’s a reason for that change…

Heroic.AutoMapper Now Supports Everything!

You can now use Heroic.AutoMapper with ASP.NET MVC 5, ASP.NET Web API, ASP.NET Core, console applications… whatever you want. There is no longer any dependency on ASP.NET or any of its infrastructure.

If you want to use Heroic.AutoMapper with ASP.NET Core, you can call it from your Startup class, like so:

using Heroic.AutoMapper;

namespace YourNamespace
{
    public class Startup
    {
        //.. snip

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseHsts();
            }

            app.UseHttpsRedirection();

            app.UseCors(x => x.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader().AllowCredentials());

            app.UseAuthentication();

            app.UseMvc();

			HeroicAutoMapperConfigurator.LoadMapsFromAssemblyContainingTypeAndReferencedAssemblies<WidgetModel>();
        }
    }
}

Want to use it in a console app? You can use this:

using Heroic.AutoMapper;

public class Program 
{
	public static void Main() 
	{
		HeroicAutoMapperConfigurator.LoadMapsFromCallerAndReferencedAssemblies();

		Console.WriteLine("All set!");
	}
}

Give It a Shot!

Installing this new version is easy:

dotnet add package Heroic.AutoMapper --version 5.0.0

Or

Install-Package Heroic.AutoMapper -Version 5.0.0

If you run into any problems, please let me know on the Github repo!

What We’ll Build

We’ll take the same approach we did in our Bootstrap-based notifications. We’ll decorate our ASP.NET Core action results using an extension method:

[HttpGet]
public IActionResult Success()
{
    return Ok(new {id = 1, name = "success"}).WithSuccess("It worked!", "All is well...");
}

Client-side, we’ll automatically grab the status and display it using angular2-notifications:

Jaspero’s angular2-notifications: A light and easy to use notifications library for Angular 2.

We’ll only write that code once, so client-side, our normal API calls will be free of any boring, repetitive logic, leaving us with simple, clean code:

async create(form: Widget) {
    const result = await.httpClient.post('/some/api', form).toPromise();
    
    // No need to manually show feedback!
}

Let’s get stated!

Project Setup

I’m going to creat a new ASP.NET Core 2.1 (preview) project with Angular. I’ve already fixed the bugs in the template and updated it to provide a better dev-time experience, like I described, so check that post if you want more information.

We’ll also need Jaspero’s angular2-notifications package, which we can install with npm:

npm i --save angular2-notifications

And we’ll need to import the module in our app.module.ts, along with the BrowserAnimationModule:

//...snip
import { SimpleNotificationsModule } from 'angular2-notifications';
import { BrowserAnimationsModule } from '@angular/platform-browser/animations';
//...snip

@NgModule({
  declarations: [
    AppComponent,
    NavMenuComponent,
    HomeComponent,
    CounterComponent,
    FetchDataComponent
  ],
  imports: [
    BrowserModule.withServerTransition({ appId: 'ng-cli-universal' }),
    HttpClientModule,
    BrowserAnimationsModule,
    FormsModule,
    RouterModule.forRoot([
      { path: '', component: HomeComponent, pathMatch: 'full' },
      { path: 'counter', component: CounterComponent },
      { path: 'fetch-data', component: FetchDataComponent },
    ]),
    SimpleNotificationsModule.forRoot()
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

The final step is to add the simple-notifications component somewhere that is available globally throughout our app. The simplest thing is to just add it to app.component.html, like so:

<div class='container-fluid'>
  <div class='row'>
    <div class='col-sm-3'>
      <app-nav-menu></app-nav-menu>
    </div>
    <div class='col-sm-9 body-content'>
      <router-outlet></router-outlet>
    </div>
  </div>
</div>
<simple-notifications></simple-notifications>

Now we can inject and use NotificationService to display the various types of notifications that are supported:

import { Component, OnInit } from '@angular/core';
import { NotificationsService } from 'angular2-notifications';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
})
export class HomeComponent implements OnInit {

  constructor(private notifications: NotificationsService) {
  }

  ngOnInit() {
    this.notifications.success('Hi!', 'Everything is initialized!');
  }
}

We’ll come back and use simple-notifications in a bit. But for now, let’s see what we need to do server-side!

Implementing Notification Extension Methods

Now we need a way to attach a notification to a response before it goes back down to our Angular app. We’re going to follow the same approach as we took for our Bootstrap-based approach, but we’ll simplify it a bit since we aren’t going to worry about ViewResults.

Here’s what our extension methods look like:

    public static class NotificationExtensions
    {
        public static IActionResult WithSuccess(this IActionResult result, string title, string body)
        {
            return Notification(result, "success", title, body);
        }

        //snip: repeat for the other notification types!
    }

And our simplified decorator:

    public class NotificationDecoratorResult : IActionResult
    {
        public IActionResult Result { get; }
        public string Type { get; }
        public string Title { get; }
        public string Body { get; }

        public NotificationDecoratorResult(IActionResult result, string type, string title, string body)
        {
            Result = result;
            Type = type;
            Title = title;
            Body = body;
        }

        public async Task ExecuteResultAsync(ActionContext context)
        {
            context.HttpContext.Response.Headers.Add("x-notification-type", Type);
            context.HttpContext.Response.Headers.Add("x-notification-title", Title);
            context.HttpContext.Response.Headers.Add("x-notification-body", Body);

            await Result.ExecuteResultAsync(context);
        }
    }

Now we can add a notification to any IHttpActionResult that we return:

return Ok(new {id = 1, name = "success"})
         .WithSuccess("It worked!", "All is well...");

Easy enough!

When a decorated action is executed, it will add three headers to the response: x-notification-type, x-notification-title, and x-notification-body.

We just need to process those headers client-side.

Displaying Notifications Automatically

So our API responses are going to have some new headers that tell us about the notification to show. We could handle those headers manually, writing code like this each and every time we invoke our API:

    const response = await this.httpClient.get<HttpResponse<string>>(`/api/some/action`, { observe: 'response' }).toPromise();

    const type = response.headers.get('x-notification-type');
    const title = response.headers.get('x-notification-title');
    const body = response.headers.get('x-notification-body');

    if (type && title && body) {
      this.notifications.create(title, body, type);
    }

But that’s terrible. We don’t want to waste time repeating that pattern. And we don’t have to!

Instead, we can leverage implement an HttpInterceptor.

This simple interceptor will do the trick:

@Injectable()
export class NotificationInterceptorService implements HttpInterceptor {

  constructor(
    //The angular2-notification service
    private notifications: NotificationsService,
    ) { }

  intercept(request: HttpRequest<any>, next: HttpHandler) {

    return next.handle(request)
      .do((ev: HttpEvent<any>) => {
        if (ev instanceof HttpResponse) {
          const headers = ev.headers;

          const type = headers.get('x-notification-type');
          const title = headers.get('x-notification-title');
          const body = headers.get('x-notification-body');

          if (type && title && body) {
            this.notifications.create(title, body, type);
          }
        }
      });
  }
}

And that’s it!

Our components can remain blissfully ignorant of these status messages:

    const result = await this.httpClient.post(`/api/widget/activate`, {id: 2}).toPromise();

And our interceptor will take care of displaying them:

Final Thoughts

So there you have it: the same pattern I’ve shown before, but this time in Angular.

If you want to check out the code, the repository is on Github.

So what do you think? Useful? Not useful? Let me know in the comments!

I’ve got more Angular and ASP.NET Core content in the works, but if there are specific topics you’d like to see, please drop me a note, and I’ll do my best to accommodate!