Could Not Find Aspnetcorev2_inprocess.dll
Marilina Crawn
I'm trying to publish an asp.net core v3 app to run under IIS. I created a virtual directory, converted to application. It has it's own IIS app pool that is setup with CLR: No Managed Code, 32 bit:False, and Pipeline:Integrated. Publishing the app to the directory, in creates the default web.config and needed json files as expected. Web.config:
If I go to my website's physical directory and manually run "dotnet .\myapp.dll", I can run it at port 5001 no problem. My client-app and api calls all work fine. When I try go to the URL under IIS, I get a 503 error, and in the event viewer:
Could not find 'aspnetcorev2_inprocess.dll'. Exception message: Could not execute because the specified command or file was not found. Possible reasons for this include: * You misspelled a built-in dotnet command. * You intended to execute a .NET Core program, but dotnet-.\PatientPlace3.dll does not exist. * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
Another clue is that the first time I go to the url, IIS starts up a w3wp process for the DefaultAppPool, not my custom CORE one. I have aspnetcorev2_inprocess.dll in all of the Program FIles\dotnet\shared[frameworkname][version] directories (2.1.8 through 3.0.0), and have the modules installed. I've tried copying that dll into my app directory, and fully qualifying the dotnet argument.
Recreating my AppPool fixed the problem. It is identical to the non-working AppPool, so it must be an order of creation issue. The first AppPool was installed before the v3 version of aspnet core module, or something like that. Thanks Lex.
Could not find 'aspnetcorev2_inprocess.dll'. Exception message: It wasnot possible to find any compatible framework version The framework'Microsoft.AspNetCore.App', version '5.0.0' was not found. - Thefollowing frameworks were found: 2.1.19
I am working on an Asp.Net Core application (MVC) using .NET5 as target framework. In my case, it was that I did not included the runtimes libraries (I mean, the folders /runtimes/win, runtimes/win-x64, and so on). I also needed to go to my WebSite in the Internet Information Services (IIS) and give permissions to the IIS_USRS user.
There is already one answer mentioning "Recreating the app pool". Since it was running already and I just exchanged some DLLs and got this issue, this could not be the problem. So in my case it was just a simple restarting of the app pool and everything worked fine again.
I tried everything. Including running the .EXE instead of dotnet + arguments (having the dll).IIS keeps on complaining about an invalid web.config.When switching to 64 bitness it will say:"Failed to find the RegisterModule entrypoint in the module DLL C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\3.1.8\aspnetcorev2_inprocess.dll."
I ran into a nasty issue yesterday related to hosting an ASP.NET Core 3.1 server application in IIS using the default InProcess hosting. If you're not familiar with ASP.NET Core hosting in IIS, here is a previous post that provides more insight on the two hosting modes, how they work and how they differ (post is for 2.2 but still applies for 3.x):
In .NET Core 3.x InProcess hosting for IIS is the default. OutOfProcess hosting externally runs Kestrel.exe and has IIS proxying requests into the external Kestrel HTTP host. InProcess hosting uses a custom IIS Module that bootstraps a custom .NET Core host right into the IIS host process which provides better performance and a smaller footprint.
Running my .NET Core 3.1 server OutOfProcess was working without problems, but as soon as I tried switching the server to InProcess I get this dreaded ANCM In-Process Start Failure error page:
The ANCM (ASP.NET Core Module) error message page is scary because it doesn't provide much in the way of debugging information on the page itself. The link at the bottom takes you to a detailed page that talks about a number of hosting failures but didn't help much in the case of InProcess startup failures.
The ASP.NET Core Module attempts to start the .NET Core CLR in-process, but it fails to start. The cause of a process startup failure can usually be determined from entries in the Application Event Log and the ASP.NET Core Module stdout log.
So the first thing I always do when I have IIS hosting startup problems is to enable the logs by turning on the stdoutLogEnabled="true" in the web.config of your server installation (or you can add a pre-configured web.config to your project).
In my case it gave me some additional - albeit not very useful - information on what is failing in the form of a stack trace that I'm outputting as part of my main program error handling. I write out the exception info which in this case turns out to be rather verbose due to a deep callstack into the runtime itself:
The code in question in my code ends at the builder.Build() call in Program.cs, which then goes into the internal CreateBuilder() functionality which then internally ends up calling the app.UseIIS() functionality that hooks up the IIS hosting. And that's when things go boom. Given that I'm failing at InProcess hosting only this doesn't exactly tell me anything new.
The startup works perfectly fine for my server in OutOfProcess hosting, but fails InProcess which is very frustrating because the expectation is that InProcess and OutOfProcess should behave very closely the same - which they mostly do, but there are subtle differences. In this case the error trace doesn't provide much help because it ends up pointing into internal code related to loading the hosting runtime dlls.
Turns out in this case that didn't help either and I didn't actually get more detailed error info because this happened as part of the initial startup sequence, but this is good advice nevertheless for startup debugging. Remember to do this only for debugging as it will slow down your application and potentially expose sensitive detail into the logs.
which gives a slight hint into what's going on. It claims that the hosting DLL aspnetcoreV2_inprocess.dll which provides the interfacing between IIS and the .NET Core code, couldn't be found. It makes sense in hindsight now that I know what's going on, but initially when I looked at the error, there was no co-relation to the fix.
The problem is that my project had a reference to a 2.2 dependency which likely got added when the project was originally created in 2.2 (or perhaps referencing some IIS specific component that I no longer use):
I removed this reference since I wasn't even sure why it's there in the first place. Nothing broke on compilation, so good on that. As soon as I removed that package reference - BOOM - InProcess hosting started to work.
According to Justin this is caused by a regression in 3.1, that's causing the old 2.2 in process handler being deployed into an unexpected location. Specifically it relates to the following two packages:
If you have explicit references to them in your 3.x projects you should be able to remove them as they are part of the ASP.NET Core Framework package. They come either from a 2.x project that was upgraded or by some fluke got imported when referencing a specific type and getting multiple choices and choosing the wrong one (ooops! been there done that).
My particular app compiles both into a published folder application as well as into a Dotnet Tool and when I looked at my pre-fix Dotnet Tool package I noticed the following 2.2 references to the Inprocess handler in the Nuget package:
Apparently when one of these 2.2 ASP.NET Core references are in the project it causes these 2.2 versions of the inprocess.dll to be deployed in the runtimes folder. But if you look back at the event log error message it appears that the application is looking for that dependency in the root side by side to the binaries in the root folder.
In a self contained deployed 3.x application the aspnetcorev2_inprocess.dll is deployed into the root folder, but with the 2.2 reference there the root folder DLL (or one of its dependencies) was not found.
I haven't tried this but if you build a framework dependent published application this issue likely won't come up because the inprocess hosting dll is part of the shared runtime and will be available as part of the shared runtime folder from which the runtime binaries are loaded.
Either way, it's a good idea to check for the errant 2.2 packages because... they shouldn't be there regardless of whether it works or not. Once I removed the 2.2 package reference shown above, the runtimes folder was removed from the NuGet Tool package and from the self-contained publish runtimes folder. The standalone published application then started working InProcess.
For all the griping about misleading error messages, this is not always the case and in fact I have to give kudos for the ASP.NET team for providing excellent error info to tricky problems in other scenarios. A few weeks after I posted this entry, I ran into another hosting startup problem and in that situation the hosting module along with the Event Log entry provided good information for tracking down the problem.
Long story short, for the original problem the 2.2 dependency is what broke the InProcess Hosting in IIS in .NET Core 3.1 for a self-contained runtime install. The 2.2 dependency can come from a direct dependency or potentially from an indirect dependency to other ASP.NET Core 2.2 references in child dependencies, so it may not be quite so easy to see where a 2.2 reference is coming from or potentially be difficult to remove if you don't control some component that's loading it. The IIS assembly should be safe to be only in Application code, buyt the Microsoft.AspNetCore reference could be more tricky if a component is referencing that.
This is a regression bug in .NET Core 3.1 and will be fixed in future updates so this bug won't be around in later updates (current version 3.1.101 which is still broken), but until this is fixed this might bite a few of you as it did me and hopefully this post makes it a little easier to find the solution.