Why Don’t My CSS Files Work on SharePoint 2019?

For those of you who may not know, I have an open source project for SharePoint called SPEasyForms. But this post is not about that, it’s about a general problem you might encounter in SharePoint 2019, which is that none of your CSS files in document libraries work. It just so happens that I first heard about this issue this week, when somebody reported SPEasyForms doesn’t work on SharePoint 2019. I had tested it in 2019 Preview, and it had worked just fine, but the preview license had expired, so I had to spend a few days standing up a 2019 RTM farm. As soon as I did that, I saw the same results as had been reported (i.e. SPEasyForms looked like crap). So I’m just using SPEasyForms to demonstrate the problem, and I’ll go on to talk about how to fix it.

Understand that this problem will affect all CSS files that are loaded out of document libraries. That includes OOB style sheets loaded out of the master page gallery. It does not affect all SharePoint 2019 installations. Like I said, my preview didn’t display this behavior, and that’s not because this only affects the RTM release. Others had already reported this issue with the Preview release. And Microsoft is aware of the problem, but nobody has explained what alignment of the stars will cause this issue, just some people have it and others don’t.

Anyway, not assuming that you know anything about SPEasyForms, it is a tool that allows you to configure OOB SharePoint forms for jQuery constructs like tabs and accordions etc., through a drag and drop IDE-like interface, no code required. After installing SPEasyForms on a site, you can go to a list and click SPEasyForms in the ribbon, and you should get something that looks like this:

However, after installing my shiny new SharePoint 2019 RTM development server, and installing SPEasyForms in a site collection, I go to configure a list with SPEasyForms, and I’m greeted with this spiffy interface:

And now I’m thinking, why does Microsoft hate me? What did I ever do to them to deserve this abuse? Clearly, none of my CSS is getting processed by the browser for some reason. But most of my CSS is actually loaded dynamically through JavaScript, in order to allow users to change the theme. So most of the time when I’ve seen anything like this ugliness in the past, it’s been because the JavaScript either isn’t loading, or it’s crashing. But that’s not the case here.

Knowing the interface as I do, I start clicking on menu items, and when I click on ‘Add Container’ the dialog I expect is indeed opening (although it too is ugly), and if I double click on one of my configured containers it does expand showing all of the fields on that container, as shown in this image:

So clearly my CSS isn’t getting applied for some other reason. I launch the browser developer tools, go to the network tab, and reload the page (clearing the cache first). Now I look through the network traffic for all of my CSS files. I’m mostly looking for error status codes, like “401 Not Found” or “403 Forbidden” or even “418 I’m a Teapot” (I’ve never actually seen this one in the wild, but one can always hope). But all of my CSS files come back with “200 Ok”. Hmmm….

So next I click on one of my CSS files to look at the request and response headers, and lo and behold, I actually find a useful clue here. In the response headers, the content type for my CSS file is identified as “application/octet-stream”. That’s certainly not right, it should be something like “text/css”. As a result, the browser is not interpreting my CSS as a style sheet, thus none of my CSS is applied.

So now I know the problem, but what the heck? Off to Bing I go (ok, maybe I went to google, but this is a Microsoft post so let’s just pretend it was Bing ;). I enter a search for “sharepoint css application/octet-stream”, and amazingly, my first hit is SharePoint-hosted CSS files are loaded as application/octet-stream. I don’t usually have this kind of luck, but this post clearly explains the problem and the solution (although the solution doesn’t contain a great deal of detail).

First, as previously mentioned, this is a known issue with SharePoint 2019 (but to be fair, it’s really an issue with IIS 7). The SharePoint team knows about it and is working on a fix. But this post is from November 2018, and one of the replies say this applies to the preview release too, but it’s now half a year later and it doesn’t appear to have been fixed in the RTM release. And also, as previously mentioned, I installed the preview and didn’t have this issue, but now I do have it with the RTM release. I don’t know why, but there was one significant difference between my two servers. I installed the preview on Windows Server 2016, but I installed the RTM on Windows Server 2019. That could easily explain the difference, but I can’t find any confirmation as to what set of circumstances leads to this issue.

Anyway, enough about the problem, let’s talk about the friggin’ solution. It turns out, that there is an IIS feature called “IIS 6 Metabase Compatibility” or “Web-Metabase”, that was enabled by default for IIS6 but is not enabled by default for IIS7. To fix this issue, you need to enable this feature. Now that’s all they say in the answer, and like I said, that’s clear enough but not very detailed. I had to root around quite a bit before I found that feature, how ’bout a picture or two, man? Thus this post.

So to fix it, you need to launch Server Manager and click on Add roles and features:

That launches the Add Roles and Features Wizard. Just hit Next -> Next until you get to the following page, and the screenshot shows where I found the feature in question:

Now I wasn’t prompted to reboot, but just FYI, I chose to reboot anyway. After which, I launch my browser and go back to my SPEasyForms editor, and I’m confronted by a disappointing lack of progress. A quick look at the network tab in debug tool reveals the obvious, the browser is using a cached version of the CSS files and it remembers the content type. The resource hasn’t changed, and the browser doesn’t know that IIS would now server it up with a different content type. Anyway, clear the cache, and Voila.

Home