Search code examples
cssasp.net-mvciisfont-facetruetype

Custom font works locally but not on server?

I have a @font-face defined in my site's cascading style sheet. This font loads fine when I browse to the site locally (served by IIS Express). However, when loading my application from my remote server (IIS 7.5) the reference to this font causes an internal server 500 error. Why does the below style work locally, but not on the server?

@font-face {
    font-family: DejaVu Sans Mono;
    src: url('../fonts/DejaVuSansMono.ttf');
}

header h1
{
    font-family: 'DejaVu Sans Mono';
    font-size: 3em;
    padding: 0;
    margin: 0;
}
Solution

  • If you check you will discover that the DejaVuSansMono.ttf file is not being copied to your server. Since it's not being copied the font file is not there for IIS 7.5 to provide. It works locally because IIS Express is able to find the file in the local directory.

    File types that Visual Studio does not recognize have their BuildAction Property set to None by default; font files are one such unrecognized type. Having a BuildAction of none means that Visual Studio will ignore this file when building your application. There are several out of the box options for the BuildAction Property:

    • None - The file is not included in the project output group and is not compiled in the build process. An example is a text file that contains documentation, such as a Readme file.
    • Compile - The file is compiled into the build output. This setting is used for code files.
    • Content - The file is not compiled, but is included in the Content output group. For example, this setting is the default value for an .htm or other kind of Web file.
    • Embedded Resource - This file is embedded in the main project build output as a DLL or executable. It is typically used for resource files.

    The most appropriate BuildAction Property setting for DejaVuSansMono.ttf is Content. By setting the BuildAction this way the file will be copied to your remote server. Unfortunately, this manual process will have to be repeated for each file with an unrecognized file type which sets developer's up for a tedious an error prone process. Thankfully, Andre Loker has a great blog post on setting the default build action for non-default file-types in Visual Studio.