The Angular project template has been updated in ASP.NET Core 2.1-preview. The new template makes several improvements over the old one. Let’s take a look!

Installation

You will need two things if you want to try out these new bits:

1. Visual Studio 2017 Preview
2. .NET Core 2.1.3 Preview 1 SDK

Microsoft claims that these preview versions install side-by-side with the production versions of Visual Studio 2017 and .NET Core. I’ve not had any issues, but your mileage may vary.

I did notice that the VS 2017 Preview version did not pick up any of my existing extensions and add-ons, including ReSharper. I had to reinstall them.

At a minimum, you’ll need to install the NPM Task Runner extension. We’ll use that to address one limitation with the new template.

Creating Our Project

Visual Studio 2017 Preview shouldn’t look much different from what you’re used to. We’ll still start by making a new ASP.NET Core Project:

Be sure you select ASP.NET Core 2.1 from the version dropdown:

And we have a new project! The structure has changed a bit. All the Angular-related files are in a new ClientApp folder:

That looks ok, but if we try to run the project…

Well, this is a preview release, so I can forgive the bad out-of-the-box experience.

The problem is that ng serve is failing. If we run the command manually, we can see why:

Time to do some minor repair work!

Resolving "Cannot find module ‘@angular-devkit/core’"

The "Cannot find module ‘@angular-devkit/core’" error is actually a known issue. It was fixed a while back, but unfortunately, the ASP.NET Core Angular project template hasn’t been updated yet.

We can fix the issue easily though. We just need to update the local Angular CLI version from 1.6.3 to at least 1.6.5.

Open a command prompt, and navigate to the ClientApp folder in your project. Then execute the following command: npm i --save-dev @angular/[email protected].

That takes care of the bug. You still need to do now is stop the existing IIS Express instance of your site (or restart Visual Studio). Once you do though, and restart your app, everything should work:

It’s a start, but there’s one big problem: it’s slow.

My dev machine is no slouch, but a simple change in SampleDataController translates to a 15-20 second delay before I see the change in my browser.

Why?

Because of the way the SPA integration is configured in Startup:

    app.UseSpa(spa =>
    {
        spa.Options.SourcePath = "ClientApp";

        if (env.IsDevelopment())
        {
            spa.UseAngularCliServer(npmScript: "start");
        }
    });

Every time we make a change to our C# code, it’s going to re-run npm start, which will start a new instance of ng serve. That’s not quick, even for a simple app. As our app grows in complexity, it’s only going to get worse.

Let’s look at a better way to handle this.

Faster Builds with Local Proxying

The ASP.NET Core SPA integration can run Angular directly, like it is now, or it can act as a proxy to an external development server. That second option would allow us to start ng serve once, then proxy requests to it.

Switch to the proxy approach is easy:

    app.UseSpa(spa =>
    {
        if (env.IsDevelopment())
        {
            spa.UseProxyToSpaDevelopmentServer("http://localhost:4200");
        }
    });

When running in development, our application now assumes our Angular application is already being served at http://localhost:4200.

But it’s not.

We could remember to run ng serve each time. Or, we could somehow get ng serve to run automatically for us when we open our project.

And that’s where Task Runner Explorer comes in.

Using Task Runner Explorer

Visual Studio’s Task Runner Explorer allows us to execute tasks from various build and scripting tools from within Visual Studio.

Since we already installed the NPM Task Runner extension, it’s capable of running npm tasks, too.

If we open Task Runner Explorer now, we’ll see that it’s currently empty:

What gives?? Our ClientApp folder has a pacakge.json in it with scripts defined! Where are they?!?

Unfortunately, Task Runner Explorer does not support package.json files in subfolders. They have to be at the root of our project.

Let’s make a simple package.json that just executes our npm start task:

{
  "scripts": {
    "start": "cd ClientApp && npm start"
  }
}

All we’re doing is changing to our ClientApp folder and executing npm start from there.

We still need to do one more thing though. Visual Studio ships with its own, extremely dated, versions of npm and node. These versions don’t work with the Angular CLI.

We can force Visual Studio to use our globally-installed versions by going to Tools > Options -> External Web Tools, and making sure the first path points to a recent version of node. I’m using nvm, so for me, that means my first path needs to be C:\Program Files\nodejs.

Now we can finally run npm start directly from Task Runner Explorer, and have it serve our Angular application:

Even better, we can bind the start task to run at startup:

Task Runner Explorer will now start preparing our Angular application as soon as we open our project, meaning it will be ready to go by the time we press F5 to run our ASP.NET Core application.

Final Thoughts

This new template is a step up from the old one. It’s built on the Angular CLI, and while it’s not fully up to date, it’s at least not horribly out of date.

It gives you hot reloading for both Angular and ASP.NET Core all at once, too!

Hopefully the couple of issues I ran into will be addressed while the templates are still in preview. If so, then this will be a reasonable starter template for new Angular+ASP.NET Core projects!

Want the updated code for this sample? You can find it on Github.