Getting a mime type based on a file name (Or file extension), is one of those weird things you never really think about until you really, really need it. I recently ran into the issue when trying to return a file from an API (Probably not the best practice, but I had to make it happen), and I wanted to specify the mime type to the caller. I was amazed with how things “used” to be done both in the .NET Framework, and people’s answers on Stack Overflow.
How We Used To Work Out The Mime Type Based On a File Name (aka The Old Way)
If you were using the .NET Framework, you had two ways to get going. Now I know this is a .NET Core blog, but I still found it interesting to see how we got to where we are now.
The first way is that you build up a huge dictionary yourself of mappings between file extensions and mime types. This actually isn’t a bad way of doing things if you only expect a few different types of files need to be mapped.
The second was that in the System.Web namespace of the .NET Framework there is a static class for mapping classes. We can actually see the source code for this mapping here : https://referencesource.microsoft.com/#system.web/MimeMapping.cs. If you were expecting some sort of mime mapping magic to be happening well, just check out this code snippet.
|
1
2
3
4
5
6
7
8
9
10
11
12
|
private sealed class MimeMappingDictionaryClassic : MimeMappingDictionaryBase {
protected override void PopulateMappings() {
// This list was copied from the IIS7 configuration file located at:
// %windir%\system32\inetsrv\config\applicationHost.config
AddMapping(".323", "text/h323");
AddMapping(".aaf", "application/octet-stream");
AddMapping(".aca", "application/octet-stream");
AddMapping(".accdb", "application/msaccess");
[...]
}
}
|
400+ lines of manual mappings that were copied and pasted from the default IIS7 list. So, not that great.
But the main issue with all of this is that it’s too hard (close to impossible) to add and remove custom mappings. So if your file extension isn’t in the list, you are out of luck.
The .NET Core Way
.NET Core obviously has it’s own way of doing things that may seem a bit more complicated but does work well.
First, we need to install the following nuget package :
|
1
|
Install-Package Microsoft.AspNetCore.StaticFiles
|
Annoyingly the class we want to use lives inside this static files nuget package. I would say if that becomes an issue for you, to look at the source code and make it work for you in whatever way you need. But for now, let’s use the package.
Now we have access to a nifty little class called FileExtensionContentTypeProvider . Here’s some example code using it. I’ve created a simple API action that takes a filename, and returns the mime type :
|
1
2
3
4
5
6
7
8
9
10
11
|
[HttpGet]
public string Get(string fileName)
{
var provider = new FileExtensionContentTypeProvider();
string contentType;
if(!provider.TryGetContentType(fileName, out contentType))
{
contentType = "application/octet-stream";
}
return contentType;
}
|
Nothing too crazy and it works! We also catch if it doesn’t manage to map it, and just map it ourselves to a default content type. This is one thing that the .NET Framework MimeMapping class did have, was that if it couldn’t find the correct mapping, it returned application/octet-stream. But I can see how this is far more definitive as to what’s going on.
But here’s the thing, if we look at the source code of this here, we can see we are no better off in terms of doing things by “magic”, it’s still one big dictionary under the hood. And the really interesting part? We can actually add our own mappings! Let’s modify our code a bit :
|
1
2
3
4
5
6
7
8
9
10
11
12
|
[HttpGet]
public string Get(string fileName)
{
var provider = new FileExtensionContentTypeProvider();
provider.Mappings.Add(".dnct", "application/dotnetcoretutorials");
string contentType;
if(!provider.TryGetContentType(fileName, out contentType))
{
contentType = "application/octet-stream";
}
return contentType;
}
|
I’ve gone mad with power and created a new file extension called .dnct and mapped it to it’s own mimetype. Everything is a cinch!
But our last problem. What if we want to use this in multiple places? What if we need better control for unit testing that “instantiating” everytime won’t really give us? Let’s create a nice mime type mapping service!
We could create this static, but then we lose a little flexibility around unit testing. So I’m going to create an interface too. Our service looks like so :
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
public interface IMimeMappingService
{
string Map(string fileName);
}
public class MimeMappingService : IMimeMappingService
{
private readonly FileExtensionContentTypeProvider _contentTypeProvider;
public MimeMappingService(FileExtensionContentTypeProvider contentTypeProvider)
{
_contentTypeProvider = contentTypeProvider;
}
public string Map(string fileName)
{
string contentType;
if (!_contentTypeProvider.TryGetContentType(fileName, out contentType))
{
contentType = "application/octet-stream";
}
return contentType;
}
}
|
So we provide a single method called “Map”. And when creating our MimeMappingService, we take in a content service provider.
Now we need to head to our startup.cs and in our ConfigureServices method we need to wire up the service. That looks a bit like this :
|
1
2
3
4
5
6
7
8
|
public void ConfigureServices(IServiceCollection services)
{
var provider = new FileExtensionContentTypeProvider();
provider.Mappings.Add(".dnct", "application/dotnetcoretutorials");
services.AddSingleton<IMimeMappingService>(new MimeMappingService(provider));
services.AddMvc();
}
|
So we instantiate our FileExtensionContentTypeProvider, give it our extra mappings, then bind our MimeMappingService all up so it can be injected.
In our controller we change out code to look a bit like this :
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
public class ValuesController : Controller
{
private readonly IMimeMappingService _mimeMappingService;
public ValuesController(IMimeMappingService mimeMappingService)
{
_mimeMappingService = mimeMappingService;
}
[HttpGet]
public string Get(string fileName)
{
return _mimeMappingService.Map(fileName);
}
}
|
Nice and clean. And it means that any time we inject our MimeMappingService around, it has all our customer mappings contained within it!
.NET Core Static Files
There is one extra little piece of info I should really give out too. And that is if you are using the .NET Core static files middleware to serve raw files, you can also use this provider to return the correct mime type. So for example you can do things like this :
|
1
2
3
4
5
6
7
8
9
10
11
|
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
var provider = new FileExtensionContentTypeProvider();
provider.Mappings.Add(".dnct", "application/dotnetcoretutorials");
app.UseStaticFiles(new StaticFileOptions
{
ContentTypeProvider = provider
});
}
|
So now when outside of C# code, and we are just serving the raw file of type .dnct, we will still return the correct MimeType.