Windows April更新后，我的应用程序退出了提供静态文件的过程

Question

I have an app where the Content folder is filled by another process that builds a frontend app, and the Visual Studio project itself doesn't know what's in the folder. I set up the web.config with a standard <staticContent> node and <modules runAllManagedModulesForAllRequests="true"> . I have my RouteConfig set up with routes.IgnoreRoute("content/*");

The app typically runs with IIS Express, but I have also run it with IIS proper.

This has all worked fine to load js, css, and other static files directly from the content folder. That is, up until I installed the Windows April update. Now every single static file request results in a 404. If I attempt to go to the physical path requested (but going through Exporer), I get the file. The files are there. The app works on Azure when I deploy it, so it must be something local.

Here's what I've tried:

• Uninstalling both IIS Manager and IIS Express, removing the appPools from c:\\inetpub\\temp\\appPools and reinstalling IIS Express.
• Removing the staticContent node and setting runAllManagedModulesForAllRequests to false.
• Giving full access to "Everybody" in the project folder and subfolders.
• Turning off UAC.

What could it be? I'm at a loss as to how to continue working after the Windows Update.

Answer 1

It appears that the update process corrupted my IIS installation in some way. I performed a Windows Refresh, installed all my tools and pulled down my app and it works just fine.

\n

Hardly a quick or easy fix, but I was up and running again after a few hours.

I found the actual problem and how to fix it.

The Windows April Update added a nifty feature where you can set case sensitivity on or off for specific folders. They also made it so that any folder created using the Linux Subsystem has case sensitivity turned on by default. Doing the same with cmd.exe or powershell.exe has case sensitivity off by default.

My app has the client portion built using node/webpack and put into the Content folder of the .Net application. When I did a Windows Refresh, I initially had built my app with cmd.exe and it worked fine. After I turned on the Linux Subsystem and built the app with bash, I started getting 404s on all of the files in the Content folder again. ProcMon.exe was telling me that the files that were failing were in uppercase (ie, if the file is modernizr.min.js, IIS was trying to open MODERNIZR.MIN.JS). I'm not sure why IIS was trying to load a file in all caps, other that the fact that when IIS caches a file, it uses all caps.

SOME SOLUTIONS

Option #1: Don't use the Linux Subsystem or Case Sensitive folders.

This problem seems to only happen when IIS is serving files from a folder with case sensitivity enabled, which happens by default with folders created in the Linux Subsystem.

Option #2: Set the Windows default for the Linux Subsystem to use case insensitivity.

Edit /etc/wsl.conf (create if it doesn't exist) and add the following:

[automount]
options="case=off"

You will need to exit the terminal and start it again for the changes to occur. Any folders previously created in bash will need to have their flags set, or be deleted and recreated.

Option #3: Update each folder's case sensitivity flag.

This could be added as part of the build script or done by hand if you don't need to repeatedly do it. You'll need to set the execution policy to be able to run powershell scripts first.

Set-ExecutionPolicy remoteSigned

Powershell Script (FixFolders.ps1):

param (
    [string]$root = $( Get-Location )
)

if ( Test-Path $root ) {

    $rootPath = $( Get-Item -Path $root )

    fsutil file setCaseSensitiveInfo $rootPath disable
    foreach ($path in Get-ChildItem -Path $rootPath -Directory -Recurse) {
        fsutil file setCaseSensitiveInfo $path.FullName disable
    }
}

This script will disable case sensitivity on the specified folder (or current folder) and all subfolders.

FixFolders.ps1 will run on the current folder and all subfolders.

FixFolders.ps1 c:\\dev will run on c:\\dev and all subfolders.