This was the solution that eventually fixed it on my machine: I moved the solution to a different folder. HUH??? How could that possibly fix this issue, I asked. After more head-banging, I eventually arrived at the root cause: a semicolon in the path. Yup. In my case, I had been storing the solution in a directory called "H:Repo (R;)
". It turns out, even though the ;
character is allowed by the Windows OS, the .NET CLR does not like it at all and doesn't know what to do with it. So it generates the unhelpful error message.
Try it out. Rename the folder of your "this should be working" solution to remove the semicolons, close and reopen the solution in VS, press F5 and watch it run. Or go to a working solution and rename the folder to contain a semicolon and watch it break the CLR.
I was curious whether any other special characters in a folder name would cause an issue, so I checked them all (on folders, not on filenames, but I'd expect a similar result for filenames too). Here's my exhaustive test:
Windows disallows these in folder names:
/:*?"<>|
The solution will load and run when the path contains any of these special characters:
`~-_+=',.()[]{}!@#$%&
However, having any of these characters in the path, while being allowed by Windows, will cause issues in the CLR or in Visual Studio:
;
Causes "HTTP Error 500.30 - ASP.NET Core app failed to start"
^
VS fails to load the solution & shows error message as follows:
"The following files were specified on the command line: <the .sln file>
These files could not be found and will not be loaded."
A totally empty instance of VS loads instead.
I also tried creating a new "hello world" console app in VS under a folder containing a semicolon in the name, and guess what? That also fails to run. Though in that case, obviously there is no HTTP error from IIS. Instead, it says
"Failed to create CoreCLR, HRESULT: 0x80070057"
and throws a process exit code. Once again, it's the result of having a semicolon in the path, because removing that semicolon from the path and reloading the solution in VS allows it to run correctly. So the semicolon issue seems to be originating from the CLR and therefore is unrelated to IIS.
Here are some related posts regarding the root cause, which is not readily apparent for web apps running on IIS Express:
Failed to create CoreCLR, HRESULT: 0x80070057
https://github.com/dotnet/sdk/issues/13954
So, kudos to those authors for those posts which were very helpful in the RCA.
One would think that the special characters allowed by the OS would also be fair game to use in the path to your Visual Studio code. Oh well. Lesson learned.