asp.net-core on Marcin Zabłocki blog

Setup ASP.NET Core 1.0 debugging on Ubuntu 16.04

Marcin Zabłocki — Tue, 24 May 2016 22:00:00 +0000

There has been a lot of excitement about running ASP.NET Core 1.0 applications on Linux. Since RC2, Microsoft provided official support for running .NET Core on Ubuntu, however up to the date of writing this post, .NET Core is officially working only on Ubuntu 14.04. What about newest version of this OS? You can easily get it work (with debugging!). Here’s the tutorial, how to run and debug ASP.NET Core 1.0 RC2 on Ubuntu 16.04.

Prerequsites

Ubuntu 16.04 installed (can be a VM)
Visual Studio Code with latest updates installed
good will

Installing .NET Core on Ubuntu 16.04 (dotnet)

Run the following commands to add the following repository package sources to your system (taken from the official Microsoft’s http://dot.net site, from Linux/Ubuntu section):

powershell

sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet/ trusty main" > /etc/apt/sources.list.d/dotnetdev.list'

sudo apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893

sudo apt-get update

Now, the original steps requires to run:

powershell

sudo apt-get install dotnet-dev-1.0.0-preview1-002702

But… there will be an error:

powershell

The following packages have unmet dependencies:
 dotnet-dev-1.0.0-preview1-002702 : Depends: dotnet-sharedframework-microsoft.netcore.app-1.0.0-rc2-3002702 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

So, let’s fix it! Trying to install the dependant package dotnet-sharedframework-microsoft.netcore.app will get you next error, saying that this package depends on libicu52 but it is not installable. Really? Head to:

powershell

http://packages.ubuntu.com/pl/trusty/amd64/libicu52/download

and download .deb package. Now, go to the download location and install the package by running:

powershell

sudo dpkg -i libicu52_52.1-3ubuntu0.4_amd64.deb

Now, you will be able to run the following commands:

powershell

sudo apt-get install dotnet-sharedframework-microsoft.netcore.app-1.0.0-rc2-3002702
sudo apt-get install dotnet-dev-1.0.0-preview1-002702

A few moments and…

powershell

dotnet --version

…yay! It’s installed.

Visual Studio Code ASP.NET Core Debugging on Ubuntu 16.04

Now, when you have dotnet installed, it’s time to setup the debugger. If already have a project to debug, that’s great. If not - download official samples from ASP.NET github repository (https://github.com/aspnet/cli-samples - remember to run dotnet restore in the project directory afterwards). After setting this up, just open project directory in VS Code.

First of all, you need Visual Studio Code C# extension. To install it, just press Ctrl+E inside VS Code and type:

powershell

ext install C#

After sucessful installation, editor will prompt you to restart. And now… another error! It says, that Ubuntu 16.04 is not supported by .NET Core Debugger. Or is it? ;]

To HACK this issue, go back to the terminal, and head to

powershell

/etc/

In this directory, there is a lot of files… And here comes the greatness of “everything-is-a-file” Linux philosophy: the /etc/ directory contains the following files:

powershell

os-release
lsb-release

Which as you might have guessed - store the information about Ubuntu version. Let’s change all of the 16.04 to 14.04 and see what happens!

powershell

sudo nano os-release

edit the file, press Ctrl+O [ENTER] to save, Ctrl+X to exit
repeat the same procedure for the next file:

sudo nano lsb-release

I provide you my files if you are uncertain how they should look:

/etc/lsb-release

html

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"

/etc/os-release

html

NAME="Ubuntu"
VERSION="14.04 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
UBUNTU_CODENAME=xenial

Go back to Visual Studio Code. Oh my goodness! .NET Core Debugger have installed! VS Code will also prompt you to add debug configuration file, click yes to generate it.

Debugging ASP.NET Core 1.0 on Ubuntu 16.04

The final step. Open debug view in Code and make sure that you have .NET Core Launch (console) selected as debug target.

Start debugging by pressing F5. Go back to your code, and mark breakpoint somewhere. The ultimate test - open web browser and hit localhost:5000 (or any other port if you have changed it)… drumroll please… Isn’t it awesome?

I hope this post helped you to fully setup ASP.NET Core debugging on Ubuntu 16.04. Happy C# coding… on Linux!

Modular ASP.NET Core 1.0 project structure

Marcin Zabłocki — Mon, 21 Mar 2016 23:00:00 +0000

ASP.NET Core 1.0 (formely ASP.NET 5) introduced some new framework concepts as well as cut loose the project structure, giving the developers ability to fully customize it. In example, we are no more bound to the Areas folder structure, which in my opinion unnecessarily duplicated Controllers/Models/Views folder structure in each of them.

Moreover, new version of the framework added a feature called View Components, which finally resolved issue of having additional controllers returning only partial views. From now on, we can make true components in ASP.NET without any workarounds.

I’ve already written a few projects in ASP.NET Core 1.0 and here is how I worked my way into creating elastic project structure.

Well structured areas

First of all - the areas. They are in ASP.NET MVC for quite a while and they are really useful. Personally, I’ve used them every time when I had to write application with both admin panel and client facing pages. The bigger part usually landed inside main project structure and the smaller one inside the Areas folder. And… I hated that. I wanted Controllers inside the Controllers folder, Views inside Views folder and Models inside Models folder. Finally - I can do that really easily.

Let’s say we have three areas: Main (client facing), Administrator and Content Authors. The output of the following configuration will look like this.

html

<projectroot>
└───Controllers
    └───Admin
    └───Authors
    └───HomeController.cs
    └───(...) other client controllers
└───Views
    └───Admin
    └───Authors
    └───Shared
    └───Home
        └───Index.cshtml
        └───(...) other client views
└───Models
    └───Admin
    └───Authors
    └───(...)HomePageViewModel.cs

As you can see, Admin and Author controllers are placed inside Controllers folder - it is where you would start looking for any controller in somebody else’s project, don’t you? The same rule applies for the Views and Models (actually - View Models) folders.

To make this structure work, the only thing we need to do is to extend Razor View Engine, so it will know how to find Views for particular Area. This can be done by implementing IViewLocationExpander interface:

csharp

public class ViewLocationExpander : IViewLocationExpander
{
    public void PopulateValues(ViewLocationExpanderContext context)
    {
        // nothing here
    }

    public IEnumerable<string> ExpandViewLocations(ViewLocationExpanderContext context, IEnumerable<string> viewLocations)
    {
        var area =
            context.ActionContext.ActionDescriptor.RouteConstraints.FirstOrDefault(rc => rc.RouteKey == "area");
        var additionalLocations = new LinkedList<string>();
        if (area != null)
        {
            additionalLocations.AddLast($"/Views/{area.RouteValue}" + "{1}/{0}.cshtml");
        }
        return viewLocations.Concat(additionalLocations);
    }
}

Now we need to attach this class to Razor engine. Head to Startup.cs and find the line in which you add MVC to application services:

csharp

services.AddMvc();

and extend this line in order to add Razor View Engine Options:

csharp

services.AddMvc().AddRazorOptions(razorOptions =>
{
    razorOptions.ViewLocationExpanders.Add(new ViewLocationExpander());
});

From now on, for every controller marked with [Area] atrribute, the framework will search for it’s views inside proper folder located under projects Views folder. Of course, this solution requires to have exactly the same name in the folder structure as in the attribute parameter. If you want to have different area name and different folder names, just add some if/switch inside of the ExpandViewLocations method and you will be good to go.

Reusable & isolated components

Some time ago, somebody asked on Stackoverflow, where the JavaScript files for the View Components should be placed in ASP.NET Core 1.0 projects. I’ve responed for that question, and here is my point of view (link to the answer bellow the post).

Isolation of components should not only consider JavaScript files, but also backing code (ViewComponent class) and the component’s view razor file. In my projects, I tend to make this kind of structure for View Components:

markdown

<projectroot>
└───Components
    └───AwesomeComponent
        └───Awesome.cshtml
        └───AwesomeComponent.cs
        └───AwesomeComponentModel.cs
    └───CommentsComponent
        └───Comments.cshtml
        └───CommentsComponent.cs
        └───CommentsComponentModel.cs

I treat every component as totally isolated entity. It is concise and it only contains necessary files. I can easily cut the component from my project and put it into another. For example, the Comments Component (actually used on this blog to show Discuss) just renders the required HTML with some dynamically rendered parameters passed to it’s view via CommentsComponentModel (which is the View Model).

View, Backend code and Model are all in one place, so when you move around the component’s folder, you are sure that you move whole component. Moreover, when you are modyfying them, you have quick access to all of their parts.

It will be convinient to put JavaScript and/or CSS files which are highly coupled with a component also in such structure. You can do this by simply creating the file under the component’s folder, and then writing a GULP TASK that will copy JS/CSS files to wwwroot. From that point, you will be able to link that JavaScript code on component’s .cshtml using standard syntax:

html

<script src="~/Components/awesomecomponent.js"></script>

After such setup, in order to render View Component with it’s parameters, use the following syntax:

csharp

@await Component.InvokeAsync("AwesomeComponent",new AwesomeComponentModel())

And remember to put [ViewComponent(Name = “Awesome”)] annotation on the top of component’s backing class if you want to avoid adding full (Name)ViewComponent convention and just have (Name)Component classes.

Additional links

My Stackoverflow anwser for “Where should my Javascript go for MVC 6 view components?” http://stackoverflow.com/questions/34932699/where-should-my-javascript-go-for-mvc-6-view-components/34933221#34933221

ASP.NET Core Redis HTML Cache

Marcin Zabłocki — Tue, 08 Mar 2016 22:51:42 +0000

Previous versions of ASP.NET MVC framework had out-of-the-box OutputCache attribute, which could be used to improve MVC aplications performance by - as the name describes - caching the output of actions to which the attribute was added.

In ASP.NET Core 1.0 (formerly ASP.NET 5) the attribute no longer exists. The ASP.NET team provided ResponseCache attribute, however it's purpose is only to set HTTP response headers, so the proxy servers behind which the web application could be running, could cache the response. What about local caching? So far, I didn't found out-of-the-box solution in the edge version of the framework (which is as of writing this post in RC1 state).

So... the need for that functionality became the code in my Visual Studio. I will show you how I've implemented full HTML cache for ASP.NET Core 1.0 using REDIS cache (and also in-proc memory), and I'll be glad to read comments about my solution and also discuss about it. Here it goes!

Implementing ASP.NET Core HTML cache

Prerequisites:

ASP.NET 5 (ASP.NET Core 1.0) RC1 installed
Visual Studio 2015
access to any Redis server*
ASP.NET dnx451 targeted project (there is no .NET Core support for Redis Cache yet)

*Redis is obviously optional when you use memory cache

Preparation

My cache solution will be a tandem of ASP.NET Middleware and C# Attribute usage. Let's start with creating new Web Application project. You will also need some additional packages, so open project.json and add those:

"Microsoft.Extensions.Caching.Memory": "1.0.0-rc1-final",
"Microsoft.Extensions.Caching.Redis": "1.0.0-rc1-final"

If Visual Studio fails to restore packages, make sure that you have proper package sources. Those are mine: (Nuget.config)

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
        <add key="AspNetVNext" value="https://www.myget.org/F/aspnetvnext/api/v2/"
        />
        <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
        <add key="Roslyn" value="https://www.myget.org/F/roslyn-nightly/" />
        <add key="DotNet" value="https://www.myget.org/F/dotnet-corefx/" />
    </packageSources>
</configuration>

How it will work

Before writing the code, here is a description how my solution will work:

Adding custom created Cache attribute adds action filter to marked action
Action filter handles those events:
1. OnActionExecuting - to prevent action executing if cached response exists, and to write cached response into current request result
2. OnResultExecuting - to finish request handling, when cache is hit
3. OnResultExecuted - when there was a cache miss, to save response into cache
Custom middleware to intercept response stream and provide own MemoryStream to which custom code will be able to write and read.w

Implementation - abstract layer

After restoring packages and setting target framework - add new folder to your project, call it Cache - all of cache related code will land there.

In order to have some abstraction and avoid hard dependencies, I've created ICacheService interface, which exposes general purpose cache methods:

public interface ICacheService
{
    void Store(string key, object content);

    void Store(string key, object content, int duration);

    T Get(string key) where T : class;
}

Implementation of this service will be described later in this post.
Next - let's add CacheAttribute class, which will implement IActionFilter and inherit from ResultFilterAttribute.

public class CacheAttribute : ResultFilterAttribute, IActionFilter
{
//...
}

Custom middleware for accessing response stream

Before writing the implementation of this attribute, we will need access to the response stream (which is somehow locked to write/read by default). In order to obtain this functionality, add the middleware class CacheMiddleware.cs. Every middleware class requires non-interfaced method with the signature as follows:
public async Task Invoke(HttpContext httpContext)

By desing, every middleware must invoke further registered middlewares, there is no exception for this one. Easiest way to do this is to add RequestDelegate dependency in constructor, so build-in ASP.NET DI container will inject this object into our middleware.

Purpose of CacheMiddleware is to intercept request, and provide custom stream to which further middlewares could write (and read). When the middleware invocation process will return to CacheMiddleware, this stream's content will be copied to original response stream. Full implementation of this class:

public class CacheMiddleware
{
	protected RequestDelegate NextMiddleware;

	public CacheMiddleware(RequestDelegate nextMiddleware)
	{
		NextMiddleware = nextMiddleware;
	}

	public async Task Invoke(HttpContext httpContext)
	{
		using (var responseStream = new MemoryStream())
		{
			var fullResponse = httpContext.Response.Body;
			httpContext.Response.Body = responseStream;
			await NextMiddleware.Invoke(httpContext);
			responseStream.Seek(0, SeekOrigin.Begin);
			await responseStream.CopyToAsync(fullResponse);
		}
	}
}

To make use of this class, we need to add it to the request pipeline. In Startup.cs file, in Configure method, just before app.UseMvc(), add:
app.UseMiddleware<CacheMiddleware>();

Cache attribute

We are now set to write CacheAttribute implementation. First, add those properties to the CacheAttribute.cs class:

protected ICacheService CacheService { set; get; }

public int Duration { set; get; }

Duration will be handy if there is any need for adjustment of cache time. Usage of CacheService property will be described shortly.

Let's move along with caching output in OnResultExecuted method:

public override void OnResultExecuted(ResultExecutedContext context)
{
	GetServices(context);

	var cacheKey = context.HttpContext.Request.GetEncodedUrl().ToMd5();
	var httpResponse = context.HttpContext.Response;
	var responseStream = httpResponse.Body;

	responseStream.Seek(0, SeekOrigin.Begin);

	using (var streamReader = new StreamReader(responseStream, Encoding.UTF8, true, 512, true))
	{
		var toCache = streamReader.ReadToEnd();
		var contentType = httpResponse.ContentType;
		var statusCode = httpResponse.StatusCode.ToString();
		Task.Factory.StartNew(() =>
		{
			CacheService.Store(cacheKey + "_contentType", contentType, Duration);
			CacheService.Store(cacheKey + "_statusCode", statusCode, Duration);
			CacheService.Store(cacheKey, toCache, Duration);
		});

	}
	base.OnResultExecuted(context);
}

What it does? First - it uses Service Locator Pattern (which you could obviously replace with proper DI-way, it was used here for the quick implementation purposes) to get access to CacheService. Then, it takes the response stream (which was provided by our custom middleware) and reads the whole of it (with leaving the stream open, thus the monstrous StreamReader constructor usage). After all of this, method stores response, response type and status code in the Cache - this process is run in the background, so the request could process further without any blocking operations. At last, the OnResultExecuted method invokes base method, so any remaining filters can execute.

Now, when we have response cached, we need a way to intercept request and write it to the response. There goes the implementation of OnActionExecuting method:

public void OnActionExecuting(ActionExecutingContext context)
{
	GetServices(context);
	var requestUrl = context.HttpContext.Request.GetEncodedUrl();
	var cacheKey = requestUrl.ToMd5();
	var cachedResult = CacheService.Get<string>(cacheKey);
	var contentType = CacheService.Get<string>(cacheKey + "_contentType");
	var statusCode = CacheService.Get<string>(cacheKey + "_statusCode");
	if (!string.IsNullOrEmpty(cachedResult) && !string.IsNullOrEmpty(contentType) &&
		!string.IsNullOrEmpty(statusCode))
	{
		//cache hit
		var httpResponse = context.HttpContext.Response;
		httpResponse.ContentType = contentType;
		httpResponse.StatusCode = Convert.ToInt32(statusCode);

		var responseStream = httpResponse.Body;
		responseStream.Seek(0, SeekOrigin.Begin);
		if (responseStream.Length <= cachedResult.Length)
		{
			responseStream.SetLength((long)cachedResult.Length << 1);
		}
		using (var writer = new StreamWriter(responseStream, Encoding.UTF8, 4096, true))
		{
			writer.Write(cachedResult);
			writer.Flush();
			responseStream.Flush();
			context.Result = new ContentResult { Content = cachedResult };
		}
	}
	else
	{
		//cache miss
	}
}

As you can see, again - I take CacheService. This time, the code searches for the same cache keys used to store response. If all keys are found (cache hit). From this point, we set response Content Type, Status Code and finally - we write cached HTML into response stream. As you can see, there is a part of code which extends stream's length. I've encountered an issue in which I could not write to the stream (because of the length issues), so I've just extended the length of it. The line which sets context.Result is very important, as the implementation of next method - OnResultExecuting - relays on it:

public override void OnResultExecuting(ResultExecutingContext context)
{
	if (context.Result is ContentResult)
	{
		context.Cancel = true;
	}
}

This code cancels the request pipeline, if there was a Cache Hit. Of course, you can create more sophisticated condition here - I'm sure that it will not work in some cases, but this post is about general idea of HTML cache, not perfect-error-resistant-uber-implemntation.

OnResultExecuted method will be left blank.

Implementing Cache Service

We are almost done. The only missing part is the actual CacheService. As promised in the title of this post - Redis cache will be used. I will also provide my implementation of MemoryCache, so you can test HTML cache without Redis server.

public class RedisCacheService : ICacheService
{
	protected IDistributedCache Cache;
	private static int DefaultCacheDuration => 60;

	public RedisCacheService(IDistributedCache cache)
	{
		Cache = cache;
	}

	public void Store(string key, object content)
	{
		Store(key, content, DefaultCacheDuration);
	}

	public void Store(string key, object content, int duration)
	{
		string toStore;
		if (content is string)
		{
			toStore = (string)content;
		}
		else
		{
			toStore = JsonConvert.SerializeObject(content);
		}

		duration = duration <= 0 ? DefaultCacheDuration : duration;
		Cache.Set(key, Encoding.UTF8.GetBytes(toStore), new DistributedCacheEntryOptions()
		{
			AbsoluteExpiration = DateTime.Now + TimeSpan.FromSeconds(duration)
		});
	}

	public T Get<T>(string key) where T : class
	{
		var fromCache = Cache.Get(key);
		if (fromCache == null)
		{
			return null;
		}

		var str = Encoding.UTF8.GetString(fromCache);
		if (typeof(T) == typeof(string))
		{
			return str as T;
		}

		return JsonConvert.DeserializeObject<T>(str);
	}
}

Implementation depends on IDistributedCache - interface provided by the ASP.NET Core 1.0 framework itself. To use it, we need to configure it. Head to the Startup.cs file again, but this time, go to ConfigureServices method and add this code:

services.AddCaching();
string redisConnection = Configuration["Redis:ConnectionString"],
	   redisInstance = Configuration["Redis:InstanceName"];

services.AddSingleton<IDistributedCache>(factory =>
{
	var cache = new RedisCache(new RedisCacheOptions
	{
		Configuration = redisConnection,
		InstanceName = redisInstance
	});

	return cache;
});

You can see that this code uses some configuration data. By default, ASP.NET Core 1.0 configuration is stored in appsettings.json file. Open it and configure your Redis instance connection strings:

"Redis": {
    "ConnectionString": "redis-server:7331,password=correcthorsebatterystaple",
    "InstanceName": "redis"
}

Last thing to do is to add implemented CacheAttribute and RedisCacheService to the application. Just add those lines bellow the previous Redis-related ones in Startup.cs:

services.AddSingleton<ICacheService, RedisCacheService>();
services.AddTransient<CacheAttribute>();

Testing the solution

OK, let's test it! I've replaced original Home/Index.cshtml with this code:

@model dynamic
@DateTime.Now
<script type="text/javascript">
    document.write("<p>" + new Date().toLocaleString() + "</p>");
</script>

and then I've added CacheAttribute to HomeController Index method:

[Cache(Duration = 30)]
public IActionResult Index()
{
	return View();
}

Now - let's start the application using dnx web (or dnx-watch web) command and open http://localhost:5000 (default URL). First request processes along the whole pipeline, but the second one responds from cache, as you can see in the screenshots bellow.

Full request

Cached request

Redis server view

Using memory to cache HTML instead of Redis

As my implementation is interface-only dependant, the RedisCacheService could be easily replaced by In-memory Cache. Here is the implementation:

public class MemoryCacheService : ICacheService
{
	protected IMemoryCache Cache;

	public MemoryCacheService(IMemoryCache cache)
	{
		Cache = cache;
	}

	public void Store(string key, object content)
	{
		Store(key, content, DefaultCacheDuration);
	}

	public void Store(string key, object content, int duration)
	{
		object cached;
		if (Cache.TryGetValue(key, out cached))
		{
			Cache.Remove(key);
		}

		Cache.Set(key, content,
			new MemoryCacheEntryOptions
			{
				AbsoluteExpiration = DateTime.Now + TimeSpan.FromSeconds(duration),
				Priority = CacheItemPriority.Low
			});
	}


	private static int DefaultCacheDuration => 60;

	public T Get<T>(string key) where T : class
	{
		object result;
		if (Cache.TryGetValue(key, out result))
		{
			return result as T;
		}
		return null;
	}
}

Wrap up

And that's it. I hope you like my post, please share or/and leave a comment! Of course, the whole source code can be found on github: https://github.com/marrrcin/aspnet-core-redis-html-cache
Please comment and share if you like it!