Still no resolution for this ?
Should we switch back to using core 2.1 for the time being ?
I added the changes to the Movie class (the Display and Column attributes)
after that I get the above error as soon as I try and navigate to:
https://localhost:44301/Movies.
It is only the Movies route that causes the 500 error, I can't find anything useful by placing breakpoints anywhere.
Various mentions online of web.config, but there IS NO web.config - only MvcMovie.csproj file and that is only available in the folder view, not in the Solution Explorer for some reason - even with the Show All Files button selected.
From my event log (if it helps):
Failed to start application '/LM/W3SVC/2/ROOT/movies', ErrorCode '0x80004005'.
Process Id: 15504.
File Version: 12.2.18292.0. Description: IIS ASP.NET Core Module V2. Commit:
b92c82e97f19f77c95752340066a64a337551e6d
There was another error at the same time:
Only one inprocess application is allowed per IIS application pool. Please assign the application '/LM/W3SVC/2/ROOT/movies' to a different IIS application pool.
(for some reason the github text editor truncates that token value above !!)
Update!!
Ok, hopefully this will help others stuck, because once again vital information was missing from a tutorial.
In VS2017, instead of running the app as IIS Express, I selected MvcMovie from the drop down options available near the green 'run' button.
This appeared to have the effect of selecting the "Project" commandName section of the launchSettings.json file (instead of "IISExpress") which indeed ties in with the tutorial which uses port 5001 (not 51687).
And now the app works fine.
Quite why the app should work properly when debugging from MvcMovie rather than IIS Express, I've no idea - perhaps someone could enlighten me.
The other odd thing is now a command window (black with white text) runs as well as the browser opening!
The assignment of a separate app pool is a requirement when using the in-process hosting model.
That's it
So how is it the app only failes when the user navigates to the movies URL ?
But isn’t in-process hosting the default for IIS ?
On Friday, March 8, 2019, Luis Harvey Triana Vega notifications@github.com
wrote:
The assignment of a separate app pool is a requirement when using the
in-process hosting model.That's it
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore/issues/8134#issuecomment-471003495,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKvNVRx0FJnjgRl47jZvlkvP5NklAp_Dks5vUpmOgaJpZM4ba-kr
.
I have got the same, just simply delete IIS
config in the launchSettings.json
file, run again, and it should work
We're getting same error msg. Application runs fine on IIS (2.2.2 inProcess) for about one week, now it suddenly started getting HTTP Error 500.0 - ANCM In-Process Handler Load Failure. A few minutes later the error dissapeared.
Nothing found in the logs.
I just started getting this issue from Azure Functions as all of my APIs (in consumption model) are hosted there. Pretty heartbreaking.
The error message I'm seeing is similar to the first post on #6111.
Drive by Googling for this error led me here...posting my solution in case it can help anyone.
Seemingly out of the blue this issue happened to me. I could run my Core 2.2 API site in Debug in IIS Express, but when I tried to get to my swagger UI endpoint (just /swagger) I'd get the error page. My fix was to delete the VS config folder (a hidden folder in the solution folder), thus deleting the applicationhost.config file. Next time VS built the solution this was recreated, and my issue went away. When I diff the applicationhost.config file between a copy of the deleted one and the new one, I can see what could have caused the error. I had tried to set the default url for my site to be root/swagger, but I did this incorrectly in my project settings. I believe this resulted in the creation of a "swagger AppPool", which is present in the old config but not the new one.
@GuitarHero1969 Thanks so much - was looking for ages to see what the issue was and choosing the "Project" instead of IIS express is what solved it.
Thanks so much - was looking for ages to see what the issue was and choosing the "Project" instead of IIS express is what solved it.
This means the app is no longer using IIS. Is that a sufficient answer for everyone on this thread?
I'd like to try and get back to the underlying IIS issue:
Only one inprocess application is allowed per IIS application pool. Please assign the application '/LM/W3SVC/2/ROOT/movies' to a different IIS application pool.
It looks like @joegithub has identified that this issue is due to a corrupt applicationHost.config
file. We believe this issue has been fixed in Visual Studio 2019 (cc @shirhatti to follow up).
I'm going to close this as we believe the underlying issue is resolved. If you are having a different issue, please feel free to file a new issue! If anyone is still having the above issue let us know.
In my case, I experienced this error on Azure App Service.
My problem was that I was compiling the web app in x64 because I read in one of the Azure App Service instance properties that the OS was 64bits, but what I took long to realize (and it was shown in far less detail, but shown nonetheless), was that the IIS PROCESS on Azure App Service was being run in 32 bits. Thus, the assembly was not valid and that caused this error to be shown.
All in all, this particular error message can be the consequence of many different things.
It would be great to have more details instead of such a generic message.
All in all, this particular error message can be the consequence of many different things.
It would be great to have more details instead of such a generic message.
That's being fixed.
cc @jkotalik
Yeah, in 3.0 we have a whole bunch of new detailed error codes. And in Development
environment you'll get detailed errors messages right on the page (or in the Windows Event Log in non-Development
environments). We're looking at how we can backport some of this to 2.1/2.2.
I wanted to debug on a different URL than the index and I made the mistake to change the "App URL" in project settings from http://localhost:23009
to http://localhost:23009/OtherPage
instead of changing the launchUrl
(not the applicationUrl
!) in launchSettings.json
for the IIS Express
profile.
It created a bunch of stuff, with a new app pool config for IIS Express and I had this error message after that when I tried to go back to "/OtherPage", after reverting to the default App URL.
I deleted all the references (3 blocks to remove) related to the additional app pool in WebApplication1\.vs\WebApplication1\config\applicationhost.config
and it worked again.
Hope this helps. 😄
Well, after one day struggling with the "HTTP Error 500.0 - ANCM In-Process Handler Load Failure" my error was in one http call to another api and an extra dose of stupidity (localhost)..
using (var client = new HttpClient())
{
client.BaseAddress = new Uri("http://localhost:55945");
...
await client.GetAsync("api/pqp-oh-boi");
}
The way i endup discover my error was through console Kudu. You can access it via Azure or directly by _https://YOUR-SITE.scm.azurewebsites.net/_ . Once in the main page, i went to _Debug console/CMD_ then _site/wwwroot_ and edit the _web.config_ file.
I set the value of stdoutLogEnabled to _true_, went back to my directory and access "LogFiles" were I can check for my error.
<aspNetCore processPath=".\Uno.ContactManager.RestApi.exe" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" hostingModel="InProcess" />
As @CesarD said
All in all, this particular error message can be the consequence of many different things.
Hope this can help someone
I closed Visual Studio and deleted hidden .vs
folder and now swagger is working again on netcore 2.2
Deleted .vs FTW! Thanks for sharing your solution @joegithub !
It looks like @joegithub has identified that this issue is due to a corrupt
applicationHost.config
file. We believe this issue has been fixed in Visual Studio 2019 (cc @shirhatti to follow up).I'm going to close this as we believe the underlying issue is resolved. If you are having a
FYI I am still getting this in Visual Studio 2019 and the solution still works.
Just got the exact same error as @joegithub in VS2019 16.2.3 while adding IdentityServer4 to an ASP core webservice and adding /.well-known/openid-configuration to the project path.
Doesn't appear to be fixed in VS2019 yet.
EDIT: Full disclosure. The error only occurs if you add your desired endpoint path to the 'App URL' field in Project Properties instead of adding it to the 'Launch Browser' path field. However, once you've made that mistake it's extremely difficult to work out what's gone wrong. Cudos to @joegithub for such a well described fix, he's clearly saved a lot of people a lot of time and effort.
Most helpful comment
Drive by Googling for this error led me here...posting my solution in case it can help anyone.
Seemingly out of the blue this issue happened to me. I could run my Core 2.2 API site in Debug in IIS Express, but when I tried to get to my swagger UI endpoint (just /swagger) I'd get the error page. My fix was to delete the VS config folder (a hidden folder in the solution folder), thus deleting the applicationhost.config file. Next time VS built the solution this was recreated, and my issue went away. When I diff the applicationhost.config file between a copy of the deleted one and the new one, I can see what could have caused the error. I had tried to set the default url for my site to be root/swagger, but I did this incorrectly in my project settings. I believe this resulted in the creation of a "swagger AppPool", which is present in the old config but not the new one.