ASP.NET 5 keeping the wwwroot 'clean'

Question

I'm working on a website and I use ASP.NET 5 CLR (rc1-final x64). I want to have my wwwroot folder 'clean'. I feel everything that should exist in wwwroot should be added on build or through tasks (for example through Grunt). I'm using Grunt for this, and this works fine with JavaScript and CSS files.

Now I'm at that point of adding images to my website. Right now my .gitignore says to exclude the wwwroot. I don't know how to move images from outside the wwwroot to inside it. Is there any good way to move files to the wwwroot? I really want my wwwroot 'clean' without any libraries. I have those outside of the wwwroot, so I don't accidentally serve unwanted files.

I want to move them from: [Application Root]/static/img to wwwroot/img.

Currently I have the following grunt tasks:

• grunt-contrib-concat
• grunt-contrib-cssmin
• grunt-contrib-uglify

I think this may be very in-efficient because on build we need to move all the files every time.

Is there any way to do this better / more efficiently?

EDIT #1: Yeah, so I read the documentation: http://docs.asp.net/en/latest/fundamentals/static-files.html. I could actually just pass in a parameter to the app.UseStaticFiles() method like this:

app.UseStaticFiles(new StaticFileOptions
    {
        FileProvider = new PhysicalFileProvider(@"D:\Source\WebApplication1\src\WebApplication1\MyStaticFiles"),
        RequestPath = new PathString("/StaticFiles")
    });

Here the PhysicalFileProvider contains the absolute path. Is it possible to use a relative path here?

EDIT #2: Actually this works:

public void Configure(IApplicationBuilder app, IHostingEnvironment environment, ILoggerFactory loggerFactory, IApplicationEnvironment appEnvironment)
{
    app.UseIISPlatformHandler();
    app.UseDeveloperExceptionPage();

    app.UseMvcWithDefaultRoute()
        .UseStaticFiles()
        .UseStaticFiles(new StaticFileOptions
        {
            FileProvider = new PhysicalFileProvider(string.Concat(appEnvironment.ApplicationBasePath,"/static/images")),
            RequestPath = new PathString("/img")
        });
}

Here we add the UseStaticFiles middleware twice to serve the default, which is wwwroot. We will also serve files from within the solution where the images are.

However, I don't know if there would be any performance or security problems or other problems by adding this middleware twice. You need to be careful in what you add in this folder. Directory Browsing should atleast not be enabled.

Answer 1

Are you sure you want to keep wwwroot "clean"?

You cannot easily reference static content outside of wwwroot so doesn't it make more sense to keep the static files below wwwroot and just segregate them into sub folders for dev vs production and then just use publishexclude in project.json to leave out the dev stuff.

Myself, I only want to run grunt tasks prior to publishing to produce the production set of files, then I want to leave the dev versions of the files out of publishing. I do not want to run grunt just to move files so I can use them during development and I don't want to run grunt every time I edit the dev/src versions of my js files.

The problem of that approach becomes more obvious if you pull in something like ckeditor which is a huge number of files that I don't want to copy or move around the file system much, at most I would move them once pre-publish to clean out any extra files as I move it to a production folder.

Back in MVC 5 there was no concept of separating the static files from the code, the web app just served files out of the same root app directory that also had server side code. At that time having static files in a /Content folder or js in other folders made sense. But trying to keep static assets outside of wwwroot in MVC6/aspnet5 seems to me to be working against the grain of the wood.

By keeping all static assets including the dev versions of them below wwwroot I have an easy workflow where I can just edit a js file and refresh the page as discussed in this question. This feels like I'm working with the framework and not against it.