Using the AspNet Core is a joy in itself, but here I make a record (mainly for myself) of creating commands for use through the Command Prompt which can be consumed by a web application.

Using commands is a common activity when you are building web applications with AspNet Core. You interact with Entity Framework through a Command Prompt through the library crated for such things. If you’ve used this you’ll be familiar with the dependency in your project.json “EnttiyFramework.Commands”.

You’ll also may or may not be familiar with these lines…

"commands": {
 "web": "Microsoft.AspNet.Server.Kestrel",
 "ef": "EntityFramework.Commands";

Anyway, those lines allow something like this..

dnx ef database update

So let’s create one of these commands for ourselves…

Before we start, if you’re new to AspNet core, or even new to .Net Core then you can get started here as you’ll need to install the .Net Core and the AspNet core stuff for this…

Getting Started with .Net Core

Also, it’s worth noting that at the time of this writing, there are things which will be renamed in the near future. You’ll also need an Asp.Net project created, I’ve built one using the Visual Studio template for Asp.Net 5 (Asp.Net Core) web application. You can also use the Yeoman generator for Asp.Net 5 if that is your weapon of choice.

Yeoman Generator for Asp.Net 5

Now, let’s get on with building our command application which will be consumed by our Asp.Net web application. This is really simple using the .Net Core; and from a command prompt in a directory of your creation to hold the application (I’ve named my directory “TestConsoleApp.Command”), execute this…

dotnet new

This will create you a basic C# console application and in your folder you’ll have a NuGet.Config file, a Program.cs and project.json.

Firstly, just to check what dependencies your project.json is referencing as some things are in beta at the moment and changing; here’s what I have.

"dependencies": {
"Microsoft.CSharp": "4.0.1-beta-23516",
"System.Collections": "4.0.11-beta-23516",
"System.Console": "4.0.0-beta-23516",
"System.Linq": "4.0.1-beta-23516",
"System.Threading": "4.0.11-beta-23516";

…and the framework is targeting “dnxcore50”.

Now, the console application generated by the dotnet core should be a simple “Hello World!” app, outputting that text to the console.

If you run…

dnu restore
dotnet build

You should find your complied dll in bun/Debug/dnxcore50; again, names of directory’s may change in the near future.

Given the directory was named “TestConsoleApp.Command”, I’m looking at a dll named “TestConsoleApp.Command.dll”. This is the dll we’ll now reference in the project.json of the web application. If you’re using Visual Studio you can add your references as normal. If you are editing the project.json file of your web application directly; you can enter this into your dependencies.

"frameworks": {
    "dnxcore50": {
       "dependencies": {
        "TestConsoleApp.Command": "1.0.0-*"}}

Then you can add your command here in the web applications project.json…
(In VS, if you save this document with changes VS will do a restore of packages. If not you can run dnu restore from the command prompt in the root of the web application’s project directory)

"commands": {
 "test": "TestConsoleApp.Command"

Once done, open your command prompt at the location of your web application and run…

dnx test

Which should produce whatever message you had set your console app to produce. There are of course other ways to do this. I’ve done this by adding a reference to the assembly from outside the web application solution. However, having the console app project in the solution is what I would say a better way to go about this because of this…

When referencing the assembly I found a few things happened. Firstly a wrap is created in the root of the web application which contains a project.json. This project.json contains a reference to the location of the assembly. Now, this is where things went a bit funny. Even though a reference is kept to its location; a copy is made of the assembly and put in the lib folder which is also in the directory of the application. Now, one may think this is a good idea as we now have a copy of the assembly close to the application. That though is where I found a little problem. When you update your assembly, that copy does not get updated automatically at the present time. I find I have to go to that directory, delete the copy-or copy the update assembly over-and re-fresh the reference; which then pulls over another copy.

Due to the nearest wins rule, it is the copy which is being used and until I found that copy being kept I did have a few hair scratching moments wondering why my updates weren’t being seen.

So there you have it, I find this arrangement is a very nice way to give a bit extra when the situation requires it but keeping it all in one neat place for usage.