.Net Client Side Libraries

In this post, I introduced (to me) a new method of installing client side Javascript libraries for a .Net Web Application.

In this follow-up, I’m going to cover how this can be used in conjunction with npm in order to simply move the files into the correct location. Note that this is a new tool in Visual Studio, and you’ll need VS 15.8.0 or higher for it to work. Let’s start by creating an empty .Net Core Web App. Once you’ve done so, you’re app probably looks like this:

Now you’ll need to launch a bash or powershell console:

npm init
npm install jquery

Refresh your project and show all files:

As you can see, you now have a node_modules directory. The problem is that the files need to be under wwwroot. Obviously, you could copy it, but let’s try the client side manager:

In the resultant dialog, select File System; navigate to the JQuery directory and select the files that you want:

Now refresh the project again and let’s see what we have:

This actually translates to a JSON file; libman.json looks like this:

  "version": "1.0",
  "defaultProvider": "filesystem",
  "libraries": [
      "library": "node_modules\\jquery\\dist\\",
      "destination": "wwwroot/lib/dist/",
      "files": [

Abusing the system

Okay – so that’s very nice; but now that we have a system that will copy files from wherever into wherever (the rule is that you have to go deeper in the files structure – so you couldn’t copy that file back again) then we, presumably, could use this for other things. For example, have you ever had a file (an image or something) that you need to include in your project:

Obviously, c:\tmp above could just as easily be \\shareddrive\images.

To be clear, I’m unsure whether this is abusing the system, or it was meant for this exact thing. It is possible that this type of usage may become unsupported in future (so you’ve been warned).

Installing Client Side Libraries in Asp.Net Core

As a relative newcomer to the web front-end, one thing that always surprised me was how many moving parts you need to get something running. This is probably true elsewhere (i.e. in back-end development, and desktop development) but we just do a better job of hiding it. In the past, people writing web-pages have always has an uneasy relationship with Microsoft. Maybe it started in the late nineties when, in order to win the battle of the browsers with Netscape, Microsoft started giving its product away. Since then IE became more and more bloated, as it had to support 10 years worth of old technology, and people have had to ensure it still worked on IE 6 and 7.

But now things are different, Microsoft is a rebranded company and nobody hates them anymore… and when you create a brand new Asp.Net Core 2.1 project, you can use npm to install client side packages, use them in your web page and it all just works – end of the post.

Except that hasn’t happened. In fact, the client side package management for the web seems (to me) to be in a bit of a mess – especially where Microsoft is concerned.

Create a brand new Asp.Net Core 2.1 MVC project from the template and it comes with jquery, supplied by bower; except Microsoft aren’t continuing support for bower anymore.

So, use NuGet to install your package?

Nope – not on .Net Core!

So, use npm – that’s still supported?

Yep – here’s the Asp.Net Signal R client side package installed using npm:

Okay, so it puts it in ‘node_modules’ – I can reference the library directly from there, right?

Nope – it needs to be in wwwroot\lib.

Errr – so I copy it across manually?

You can. Although that’s kind of the problem that package managers were invented to solve.

I can create a gulp task to take the files out of the downloaded directory and place them into the lib directory!

Yes – yes, you can. Although now you have a gulp task, and an npm restore, all so that you can include one or two files in your project. This all just seems too hard!


Introducing LibMan. It isn’t a Package Manager; but it might just be the correct answer to the question: “Why the hell is this whole thing so difficult – I only want one file!”

Here is the context menu for the in the lib folder after v15.8 (this has been available in preview for a while):

That gives you the following dialog:

This is amazing, I can pick the library that I want, and where I want it to go! I can also select specific files that I want – this almost feels like a sensible way to manage client side packages. Click install and bang:

You can see what it’s done by either selecting “Manage Client Side Packages…” from the solution context menu:

Alternatively, you can just have a look at the libman.json file (they both do the same thing as of 15.8.7, which makes me wonder whether “Manage Client Side Packages…” will do something different one day – the ellipses kind of give it away).

And There’s More…

There’s a CLI for it (which seemed to balk a bit when I tried to install it via NuGet), and you can use this as a replacement for Gulp to copy files around, by just selecting “File System” as the source (although this sort of solves that problem further down the tree).





Short Walks – Navigating in ReactJs

When you start using the React sample templates, one thing that you’ll notice is the navigation menu; it tends to look like this:

<div className='navbar-collapse collapse'>
    <ul className='nav navbar-nav'>
            <NavLink to={ '/' } exact activeClassName='active'>
                <span className='glyphicon glyphicon-home'></span> Home

After messing around for a while, you’ll probably think: now I need to navigate somewhere from within the code of the tsx/jsx file. Turns out you need to use `.push()`:

import { NavLink } from 'react-router-dom';

. . .

.then(output => {

Not exactly intuitive. And even less intuitive is if you want to go back. You’re thinking it must be `.pop()`? So was I; it’s actually:

import { NavLink } from 'react-router-dom';

. . .

.then(output => {

Fixing CSRF Vulnerability

One way that your web-site might be vulnerable to an attack is via Cross Site Request Forgery (CSRF or XSRF).

If you’ve ever been logged into a web-site – say Twitter for example – and you open a separate tab, then type in a twitter account, for example: https://www.twitter.com/paul_michaels, you’ll notice that when the site opens, it opens already logged in for you – which is very helpful. Imagine having to re-log-in every single time you wanted to view a tweet or a profile.

Okay, now imagine that, instead of typing that into the browser, you click the link above – try it! What – it didn’t take you to Twitter, but it took you to the home page of this blog? In fact, that’s exactly how a CSRF attack would work in practice. If you were already logged into that site, the link could have executed a CSRF attack.

Cross Site Request Forgery works on the premise that the victim of the attack is actually logged into a given website with valid credentials, and the attacker knows the exact format of a valid request. So, for example, I can take you to my Twitter profile, because the format of that is well known. Nobody, least of all Twitter themselves, want you to have to mess around logging in again.

But what about if you want to actually post a Tweet? Here’s the Url that gets called:

It’s a little difficult to demonstrate, because Twitter operates over HTTPS, so the traffic is encrypted, but the gist is that, even if I managed to create a site that copied this message exactly, the Tweet would not get created. Let’s have a look at replicating such an attack.

To Reproduce

Your first step is to create a really bog standard web site – the default MVC template will do. It might also help to demonstrate if you don’t use HTTPS.

Launch the web-site with F12 tools and make a given request. For example, click the “Contact” link on the default site. Make a note of the URL and the form data for the request:

Leave the app running and logged in.

Now Attack

Create a new web app with the following code:

<h1>Run CSRF Attack on MyApp</h1>
<form action="https://localhost:12312/SendLoadsOfMoney" method="post">
    <input type="hidden" name="values" 
           value="{'BankName': 'Big Bank', 'Amount': '1234.12' }">
    <input type="submit" value="Attack Now!">

Obviously, don’t use that code – otherwise you’ll cause over a thousand pounds to be transferred from my account to yours! Replace the URL with whatever the URL from the above site was, and the values with whatever values were behind your grey box above. You can use POST or GET or whatever else you like. What you’ll notice is that clicking your button interacts with the site you created in the same way as it would if you were on your site. The “SendLoadsOfMoney” is obviously an example that takes it to the extremes, but the principle is correct.


To fix this in MVC is very easy.



If you add this to the controller method, you should start seeing this error:

The required anti-forgery cookie “__RequestVerificationToken” is not present.

Your calling code might look like this:

<form action="Test" method="post">
    <input type="submit" value="Test3">

The next step is to add a call into the client; for example:

<form action="Test" method="post">
    <input type="submit" value="Test3">

So far, so good. This works for Asp.Net Mvc Core and Framework, but not for ApiControllers! The decorator [ValidateAntiForgeryToken] has no effect on an ApiController out of the box (and worse, you’ll never know it without launching a specific attack on your ApiController). So what can you do?

One option is to implement a custom token as described here. I would treat this as a specific case for ApiControllers only, though.







Microsoft Chat Bot Framework – Up And Running

Some time ago (think early to mid-nineties), I used to run a BBS. One Christmas, I logged onto another BBS based in Manchester, and they had a “Santa Chat”. I tried it for a while, and was so impressed by it, that I decided to write my own; it was basically the gift that kept giving: you put this thing on your BBS (basically an Eliza clone) and it records the responses of the unsuspecting users to a text file (or log).

These days there are laws against recording such things, but those were simpler times, and once they realised the joke, everyone was happy, and life went on (albeit at 14.4k bps).

A few years ago, I decided to relive my youth, and wrote an app for the Windows Store – this one didn’t keep logs, although I imagine, had I added a “Post Log to Facebook” button, it probably would have got some use. It has since removed by MS in their wisdom. There was very little difference between it and Eliza.

Now, Microsoft seem to have jumped on this bandwagon, and they have released a framework for developing such apps. Clearly their efforts were just a copy of mine… well, anyway, this is a quick foray into the world of a chat bot.

You’re first step, in Azure, is to set-up a Web-App bot:

This will actually create a fully working bot in two or three clicks; select “Test in Web Chat” if you don’t believe me:

Okay – it doesn’t do much – but what it does do is fully working! You can download the code for this if you like:

The code doesn’t look too daunting when you download it:

In fact, looking inside MessagesController, it appears to be a simple API controller. In fact, the controller selects a dialog to use, and the dialog is the magic class that essentially controls all the… err… dialog. The default is called “EchoDialog”.

For the purposes of this demo, we can change the part we want using the web browser; select Online Code Editor:

The bit we’re interested in for the purpose of this is the EchoDialog. Let’s try changing the text that gets sent back a little; replace the test in MessageReceivedAsync with this:

public async Task MessageReceivedAsync(IDialogContext context, IAwaitable<IMessageActivity> argument)
    var message = await argument;
    if (message.Text == "reset")
            "Are you sure you want to reset the count?",
            "Didn't get that!",
            promptStyle: PromptStyle.Auto);
        if (message == "test")
            await context.PostAsync("Testing 1, 2, 3...");
            await context.PostAsync($"{this.count++}: You said {message.Text}");

So, we are checking the input, and where it’s “test”, we’ll return a slightly different response. You’ll need to build this; select the “Open Console” button down the left hand side of the screen and type “build”:

When it’s done, open up your test again and see what happens:

Remember that the bot itself is exposed as an API, so you can put this directly into your own code.




Set-up a new Asp.Net Core 2.1 Project with Docker

Until recently, I’ve pretty much managed to avoid the container revolution. However, as the tools are becoming much more integrated, and the technology much more pervasive, I thought I’d document my journey into the world of containers.

As far as I can tell, the battle between types of containers and orchestrators is now over, and the VHS has emerged as Docker and Kubernetes; at least, MS, Google and Amazon seem to think so.

Docker – from step 0

Let’s follow the process through from nothing; the first step is to visit the Docker Store here.

Once you’re there, you’ll need to pick a username and sign in. After this, you can download Docker for Windows:

Once downloaded, run it, and you’ll see this bizarre screen, that seemingly lives in your way:

You can just close this: docker actually lives in your system tray. Right click there and select Settings:

Share your drive that you’re planning to run your Asp.Net Core code from.

By default, docker installs with a Linux bias, so the next step is to switch to Windows Containers (again in the right-click context menu):

Finally, some code…

Okay, Docker is now primed and ready to run a container. Let’s create our new project:

After you okay this, you’ll notice that there’s a new “Add Docker Support” in the create Project dialogue:

Once you create this (and persuade your browser and Docker that you’re not too bothered about certificates for the minute) it should run out of the box:

To prove it’s running, open Power Shell and type:

 docker ps

Or, to take the more brute force approach by just restarting docker and have a look at VS:




Unit Testing With Entity Framework and Entity Framework Core 2.1

Entity Framework Core 2.1 comes with a nifty little feature: an In Memory Database setting. What this means, is that with a single option setting, your tests can interact directly with the database (or at least EF’s impression of the database) but not actually touch any physical database. In other words, you can write unit tests for data access; an example:

// Arrange
DbContextOptions<ApplicationDbContext> options = new DbContextOptionsBuilder<ApplicationDbContext>()

using (var context = new ApplicationDbContext(options))
	ResourceCategory resourceCategory = new ResourceCategory()
        Name = "TestCategory"
// Act
// Assert                
Assert.Equal("TestCategory", context.ResourceCategories.First().Name);               

To just quickly explain what this is doing: we have a DbContext called ApplicationDbContext and we’re building a set of options on top of that context. We’re then instantiating the context and cleaning the in memory database. Finally, we’re adding a new piece of data to the context and then asserting that it has been added.

Told you it was nifty.

But what about if you’re still using Entity Framework 6?

Glad you asked.

Out of the box, EF does not come with this kind of functionality; however, I recently came across (and contributed) to a NuGet library that provides just such a facility. It provides a wrapper for both Moq and Nsubstitute. The GitHub Repo is here.

ReadOnly Entity Framework

Ever come across a situation where you want to use an Entity Framework data layer in a little tool or report, but ended up reverting to Ado.Net or a different ORM because EF is a little bit like a Heisenberg Framework (it changes things that it looks at)? You might have a seed method that tries to update data, or a migration that you don’t want to apply.

Apologies in advance if this seems like stating the bloody obvious; but it didn’t seem obvious to me at the time. If there’s a neater way to do this then please let me know.

Anyway, I recently had this issue, and came up with the idea of a ReadOnly DBContext. For example, your main DBContext might look like this:

    public class MyDbContext : DbContext, IMyDbContext
        static MyDbContext()
            Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyDbContext, Configuration>());
        public MyDbContext()
            : base("connection-string")
        public MyDbContext(string connectionString)
            : base(connectionString)
        public DbSet<Entity1> Entity1 { get; set; }
        public DbSet<Entity2> Entity2 { get; set; }
        void IMyDbContext.SaveChanges()
        Task IMyDbContext.SaveChangesAsync()
            return base.SaveChangesAsync();
        protected override void OnModelCreating(DbModelBuilder modelBuilder)
                .HasOptional(a => a.Field2)

Making a ReadOnly version of this is pretty much removing the code; for example:

    public class MyReadOnlyDbContext : DbContext, IMyDbContext
        static MyReadOnlyDbContext()
            Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyReadOnlyDbContext, Configuration>());
        public MyReadOnlyDbContext()
            : base("connection-string")
        public MyReadOnlyDbContext(string connectionString)
            : base(connectionString)
        public DbSet<Entity1> Entity1 { get; set; }
        public DbSet<Entity2> Entity2 { get; set; }
        void IMyDbContext.SaveChanges()

        Task IMyDbContext.SaveChangesAsync()
		  return Task.CompletedTask;

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
                .HasOptional(a => a.Field2)

An easy way to return the read only version, rather than the main version is via a DbContextGenerator:

public class DbContextGenerator : IDbContextGenerator
    private readonly AppSettings appSettings;        
    public DbContextGenerator(AppSettings appSettings)
        this.appSettings = appSettings;            
    public IMyDbContext GenerateDbContext()
        if (appSettings.ReadOnly)
            return new MyDbReadOnlyContext(appSettings.DatabaseConnectionString);
        return new MyDbContext(appSettings.DatabaseConnectionString);                        

This can be registered in the IoC and will return a DB Context based on a read only flag.

It’s worth noting that if your model doesn’t match, it will likely crash. It’s also worth noting that if you’re reading this article and trying to work out how you can use EF without having it manage the DB then it’s probably because something, somewhere, went wrong: this isn’t a suggestion for a new way to use EF, it’s a way to use EF in a temporary fashion.

Adding ReactJS to an existing Asp.Net Core 2 Application

I’ve recently been playing around with writing an Asp.Net Core 2 app from scratch. If you’re interested, you can view my exploits here.

I came across an interesting issue, which was that I wanted to search an in memory set of data, and I wanted the screen to update as I searched. React sounds like the perfect tool for this; and this article describes how to integrate a React view (JSX file) into an MVC view.

(Note that it doesn’t cover implementing the search function – that will be the subject of a later post when and if I work out how to do it.)


After you’ve created your Asp.Net Core 2 application, the first step is to install React; which is a NuGet package:

Install-Package React.AspNet -Source nuget.org

There are some code tweaks that are needed; the first is in startup.cs (which basically tells Asp to use React, and how to do so):

services.AddTransient< …
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
app.UseReact(config =>

You’ll need to slightly change the signature of ConfigureServices, too:

public IServiceProvider ConfigureServices(IServiceCollection services)
. . . 
    return services.BuildServiceProvider();

The next thing is to make React available to your views; in ViewImports.cshtml:

@using UsefulSites.Web
@using UsefulSites.Web.Models
@using UsefulSites.Web.ViewModels
@using React.AspNet
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

React Code

Next step is to create the ReactJs file:

class SearchBox extends React.Component {
    render() {
        return (
            <div className="search-container">
                    Search Text
    <SearchBox />,

Then change the HTML file:

<div class="row">
    <div class="jumbotron">
        <div id="content"></div>
        <script crossorigin src="https://cdnjs.cloudflare.com/ajax/libs/react/16.4.0/umd/react.development.js"></script>
        <script crossorigin src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/16.4.0/umd/react-dom.development.js"></script>
        <script src="@Url.Content("~/js/search.jsx")"></script>

As you can see, the React script references the div named “content” specifically.




Setting up an Azure B2C Tenant

B2C is (one of) Microsoft’s offering to allow us programmers to pass the business of managing log-ins and users over to people who want to be bothered with such things. This post contains very little code, but lots of pictures of configuration screens, that will probably be out of date by the time you read it.

A B2C set-up starts with a tenant. So the first step is to create one:

Select “Create a resource” and search for B2C:

Then select “Create”:

Now you can tell Azure what to call you B2C tenant:

It takes a while to create this, so probably go and get a brew at this stage. When this tenant gets created, it gets created outside of your Azure subscription; the next step is to link it to your subscription:

Once you have a tenant, and you’ve linked it to your subscription, you can switch to it:

If you haven’t done all of the above, but you’re scrolling down to see what the score is for an existing, linked subscription, remember that you need to be a Global Administrator for that tenant to do anything useful.

Once you’ve switched to your new tenant, navigate to the B2C:

Your first step is to tell the B2C tenant which application(s) will be using it. Select “Add” in “Applications”:

This also allows you to tell B2C where to send the user after they have logged in. In this case, we’re just using a local instance, so we’ll send them to localhost:

It doesn’t matter what you call the application; but you will need the Application ID and the key (secret), so keep a note of that:

You’ll need to generate the secret:


Policies allow you to tell B2C exactly how the user will register and log-in: do they just need an e-mail, or their name, or other information, what information should be available to the app after a successful log-in, and whether to use multi-factor authentication.

Add a policy:

Next, set-up the claims (these are the fields that you will be able to access from the application once you have a successful log-in):


That’s it – you now have a B2C tenant that will provide log-in capabilities. The next step is to add that to a web application.