Static Files in ASP.NET Core

An ASP.NET Core Web Application is very strict about only serving resources from its Web Root, which is normally <website-root>/wwwroot. This is to prevent files that could help attackers compromise your site from being served. When you build, you use a tool like Gulp, any other, or just copy and paste, to move all files that must be served into wwwroot. Just to keep things even tighter, by default, no static files will be served from this folder.

To allow your app to serve static files from its Web Root, you must install the Microsoft.AspNetCore.StaticFiles package. You can do this using NuGet, or in the nice new way that .NET Core allows: just add the line "Microsoft.AspNetCore.StaticFiles": "1.0.0" to the dependencies object in your project.json file. As soon as you save that file, Visual Studio will automatically download and install the package. Some more magic: if you don’t just copy and paste that line into project.json, after you type the package name and colon, when you type the opening double-quote for the version, the editor will give you Intellisense for which versions are available. Normally you would just choose the latest.

After adding the StaticFiles package, you need to add the following two lines to the Configure method of your project’s Startup.cs class:

app.UseDefaultFiles();
app.UseStaticFiles();

The first line means that Kestrel will look for default files, like default.html and index.html, in the Web Root folder, and automatically serve them if no other page is requested in the URL. For some mysterious reason, this line must always be placed before the static files line.

You can change which directory static files may be served from, but, for what I think was a very bad design decision, the application can always serve static files from one directory only. Maybe one day we’ll find out why.

Now if you have used any npm packages in your project, they are installed into a folder called node_modules. After adding just a few modules, this folder can become full. On a simple little Hello world type project with Angular 2, my node_modules folder contains 16,847 files, and takes up 107MB of disk space. Node.js, what is your story, coming in and making tiny, thin .NET projects obese?

The problem with npm is that all the JavaScript files that you must add to your web pages reside somewhere in node_modules, and they won’t be served, because the app is only serving static files from wwwroot. To remedy this, I had ended up with my Configure method looking like this:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    app.UseDefaultFiles();
    app.UseStaticFiles();
    app.UseFileServer();
    var provider = new PhysicalFileProvider(Path.Combine(env.ContentRootPath, "node_modules"));
    var options = new FileServerOptions();
    options.RequestPath = "/node_modules";
    options.StaticFileOptions.FileProvider = provider;
    options.EnableDirectoryBrowsing = true;
    app.UseFileServer(options);
 
    loggerFactory.AddConsole();
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
}

I have since found out that UseFileServer() incorporates the functionality in those two lines in my first code block, so I am investigating removing them and only using UseFileServer(), but for now my app works as is, and I will only update this post after some thorough testing.

The Promised ReadMe File for the Angular 2 Tutorial Project

In yesterday’s post I described a little project where I had integrated the Angular 2 QuickStart tutorial from Angular, into an ASP.NET Core web application. I also promised to add a missing readme file to the project to help developers understand how I “merged” the two.

This is cutting edge stuff, but the first step is very simple and aimed at beginners. Yet with new tech, we are all always a beginner at something.

So, the code is on GitHub, over here: https://github.com/erisiasoft/Angular2Tutorials

Angular 2 QuickStart Tutorial Code in an ASP.NET Core Application.

tl;dr: The code is here. The tutorial is there.

Discontinued: This would-be series of articles on Angular 2 has been discontinued This is in favour of a soon to begin alternative series of dotnet based tutorials for Angular 4.

I can’t learn Angular 2 fast enough for my intuition that it will be a lot bigger than Angular 1. There are billions of examples and tutorials out there, most of them inaccurate and contradictory. Not to mention hopelessly out of date with the pace ASP.NET Core has been released at. I decided to stick to the official documentation at Angular first, which is available in TypeScript, JavaScript, and Dart language flavours.  I chose TypeScript because I want to learn it, and both Microsoft and Angular are heavily behind it. It should go places, plus it’s very sweet to use.

The docs start with a tutorial called QUICKSTART, which is a little too minimal, but enough to get started. The classic Hello World pattern. They do build on this in the next tutorial though, Tour of Heroes.

The tutorials, however, are bare minimum sets of files, in effect only the files you would deploy to your web server, and not in a project format for any IDE. QuickStart introduces four core files that nearly all Angular 2 apps need, and I thought it would be interesting, and quite easy, to create a .NET Core Web Application, and just copy those files into the application. About 5 hours later, I had my Hello World working, displaying a sentence on the screen.

There were a few version incompatibilities between frameworks and platforms included in the .NET app, a few other nigglies, but the biggest problem is that, by default, a .NET Core web app will only serve resources its wwwroot folder, and then it will still not serve any static file at all, even from that folder. Request any static file and you get an HTTP  404.

To set this right, I had to add the Microsoft.AspNetCore.StaticFiles package to the project, and add a few lines in Startup.cs. For now, just create a new, empty .NET Core web app, and compare its Startup.cs to mine.

This post is not about the all the little changes I made to get Angular 2 working in the .NET app, but it is to tell you that project is on GitHub if you want to play with Angular 2 in a .NET Core web app, but couldn’t be arsed to spend the time squeezing Angular into Core. The app is available at https://github.com/erisiasoft/Angular2Tutorials, and is a tad untidy, but the important part is the HTML and TypeScript (and JavaScript, if you want) stuff is working, so if you stick to messing about with the TypeScript classes in the app folder, and HTML files in the wwwroot folder, you too can get started on the beginner level Angular 2 tutorials.

This project is not documented yet, so please leave a comment or email me at info@erisia.com if you have any questions. I will post an overview readme as soon as I have found it again, later tonight.

In my next post I will detail the process of fitting Angular 2 to a .NET Core web app, and may proceed onto writing about the Tour of Heroes tutorial, which actually has a proper GUI that does things.

 

 

DLL Hell returns: EF Core (EF 7) scaffolding is broken by version mismatches.

I have spent the last several hours trying to use EF Core’s CLI scaffolding to reverse engineer (or scaffold) a small database into entity classes. First, it simply does not support scaffolding into a Core (or any) class library. Scaffolding is done with a command much like the following one.

dotnet ef dbcontext scaffold "data source=(local);initial catalog=HawkHead;integrated security=SSPI;multipleActiveResultSets=True" "Microsoft.EntityFrameworkCore.SqlServer" -c HhDbContext -o Data

Executing this on a class library results in an error that simply tells you that scaffolding to class libraries is not supported. One would think a quick and easy workaround would be to create a .NET Core Console Application, but then executing the above command results in any number of intractable exceptions. The most understandable one was that “Microsoft.EntityFrameworkCore.SqlServer.Design”: “1.0.1” was not compatible with “Microsoft.EntityFrameworkCore.Tools”: “1.0.0-preview2-final”. There is no higher version for “Tools”, despite MS bragging that Core was now RTM and will save the fucking world.

There is, however, a very simple workaround. Add an old fashioned .NET 4.6 Console Application to your solution, add EF 6 to it, use EF 6 to do your scaffolding, and because the entity classes are POCOs, you can just copy and paste them all into your new, trendy .NET Core class library, and they work just the same with EF Core (EF 7).

Erisia Software has a New Home.

This site will feature case studies of Erisia Software in delivering top quality information solutions, as well as news on information technology in general, and some educational material on software development. For now, this blog will concentrate of Angular 2 and .NET Core.

But right now, my clients are much more important than my website, so content will slowly begin to appear over the next week or two, and then later more regularly.