2

I have an API-only site (no pages) that is terminating as soon as it starts.

I found the following errors in Event Viewer.

Application: w3wp.exe
CoreCLR Version: 6.0.21.52210
.NET Version: 6.0.0
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.EntityFrameworkCore, Version=6.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
File name: 'Microsoft.EntityFrameworkCore, Version=6.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
   at Program.<Main>$(String[] args)

And...

Application '/LM/W3SVC/18/ROOT' with physical root 'C:\inetpub\wwwroot\tt.railtrax.com\' hit unexpected managed exception, exception code = '0xe0434352'. First 30KB characters of captured stdout and stderr logs:
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.EntityFrameworkCore, Version=6.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
File name: 'Microsoft.EntityFrameworkCore, Version=6.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
   at Program.<Main>$(String[] args)

When I look at Microsoft.EntityFrameworkCore.dll in my deploy folder, it appears to be version 6.0.21.

Microsoft.EntityFrameworkCore.dll

Package Manager says I have 6.0.1 installed. So I don't know why I have 6.0.21, or if it should work with that version.

Microsoft.EntityFrameworkCore Package

Does anyone know if these version discrepancies matter, or what else I could try to resolve this?

The project is running fine on my own computer. I very recently upgraded all the suggested packages in Package Manager. I assume it happened as a result of that.

UPDATE:

Some additional information:

  • As can be seen from the error message, the project I'm having trouble with is TTRailtrax.
  • TTRailtrax has a dependency on RailtraxCore, which has Microsoft.EntityFrameworkCore.dll installed.
  • I am deploying to a local folder and then manually copying those files to the server. This has been working until now.
  • The only thing I can think that changed is that I updated the recommended NuGet packages.
  • The project continues to run fine on my local computer.
  • I have confirmed the same version of Microsoft.EntityFrameworkCore.dll exists on my local machine and the server.
  • I have cleaned my solution.
  • I uninstalled and then re-installed Microsoft.EntityFrameworkCore.dll twice now.
  • I have restarted the app on IIS several times.
  • I have redeployed to the server several times.
  • I have updated Visual Studio to the very latest version.

UPDATE:

Upon further investigation, I see that my bin\Release\net6.0 folder, contains Microsoft.EntityFrameworkCore.dll with product version 6.0.1. But then in my deployment folder, this file has product version 6.0.0.

It seems highly likely that this is related to the issue I'm seeing. Under what circumstances would a different DLL version be placed in my deployment folder than the one in my bin folder?

I tried copying the file from the bin folder but that didn't help.

Jonathan Wood
  • 65,341
  • 71
  • 269
  • 466
  • 1
    how did you actually publish and run in its? – Daniel A. White Dec 17 '21 at 01:23
  • @DanielA.White: I published to a folder, and then copied those files to my server. This has always worked in the past. – Jonathan Wood Dec 17 '21 at 01:24
  • with the framework that is the step but with .net core you have to publish it to be a standalone i think – Daniel A. White Dec 17 '21 at 01:25
  • @DanielA.White: Not sure which setting you mean, but I'm using the same settings I was using before and it was working. The only thing I can think that changed was that I updated a bunch of packages. – Jonathan Wood Dec 17 '21 at 01:27
  • can you try copying content of ../bin/Release/net6.0/ instead of ../bin/Release/net6.0/publish/ content to the server? – Metin Dec 17 '21 at 03:54
  • @Metin: Well, That still doesn't work, although the error is different. I can't find anything in Event Viewer, and the API is now just returning 404. – Jonathan Wood Dec 17 '21 at 04:02
  • @JonathanWood if there were any problems with ASP.NET Core 6 and EF Core 6 thousands of developers would have noticed. I've been using ASP.NET Core 6 and EF Core 6 since the fist preview. You *should* publish, eg using `dotnet publish -c Release`. You *shouldn't* copy the contents of `bin/Release`. If anything, if you publish a self-contained app or single-file executable, `bin/Release` won't contain the files you need. As for what's wrong in your case, 6.0.1 is the package version, not the *file* version. What does your `csproj` contain ? Does it reference EF Core 6 directly? – Panagiotis Kanavos Dec 17 '21 at 11:16
  • Which of these projects do you publish? Which one is the root project? `RailTrax` doesn't have a package reference to EF Core for example. Did you clean the `bin` folder before publishing? At least `dotnet clean -c Release`, to ensure there are no leftovers from previous builds. In some cases deleting `bin\Release` before publishing could be a good idea, in case `dotnet clean` misses files generated by build steps with no equivalent clean operation – Panagiotis Kanavos Dec 17 '21 at 11:21
  • Are the `Microsoft.EntityFrameworkCore.dll` files in your `publish` and `wwwwroot` folder the same? Perhaps there was a problem when copying the published files to production. If the site was active you wouldn't be able to overwrite the existing files, you'd have to recycle the app pool before copying. You can also try running your site from the command-line in your publish folder. This can help especially with ANCM errors – Panagiotis Kanavos Dec 17 '21 at 11:26
  • @PanagiotisKanavos: Microsoft is constantly publishing updates and fixes to .NET, so ruling out any problem doesn't make sense. I use the Publish command to publish to a local folder, and then I manually copy those files to the server. I only tried copying from the Release folder because that's what someone suggested. Since I copy the files manually, I know the same file exists on the server. *TTRailtrax* is the project I'm deploying, and it depends on *RailtraxCore*. – Jonathan Wood Dec 17 '21 at 15:44
  • Is there a web.config file in your app on the server? Does it have binding redirects? – mxmissile Dec 17 '21 at 16:51
  • @mxmissile: No redirects in *web.config*. – Jonathan Wood Dec 17 '21 at 16:53
  • 1
    Does your site have dependencies that also use efcore? Are all dependencies up to date regards version? (nuget package manager consolidate tab). I've had it before that mismatched versions have been coalesced on publish and a later-built project with a reference to an old package has overwritten the earlier-built later package (2 projects, projectA uses libraryX v1, projectB uses libraryX v2, project B builds first, then A builds and overwrites the newer libX that B has with the older libX that A uses) – Caius Jard Dec 20 '21 at 07:44
  • @CaiusJard: They all use the same version as you can see in my screenshot. In fact, since all projects also depend on *RailtraxCore*, I uninstalled *Microsoft.EntityFrameworkCore* from all projects except *RailtraxCore*. Then, only one project referenced this package. Everything compiled and ran successfully on my local system. But I get the same error when I deploy it. – Jonathan Wood Dec 20 '21 at 17:24
  • try to decompile the dll with dotpeek. It will show you the actual framework version. Not sure why do you think that the file version will match the framework version. – Vadim Dec 21 '21 at 07:47
  • Not sure if this could help, but you may want to take a look at https://learn.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer. fuslogvw might allow you to see more details as to why this binding happens the way it does. – Alexandru Clonțea Dec 21 '21 at 12:21
  • Oh, now I see, this is .net core. Read https://github.com/dotnet/runtime/issues/7693 instead :) – Alexandru Clonțea Dec 21 '21 at 12:32
  • 1
    delete all ```bin``` and ```obj``` hidden folder from your project>> clean the solution>> Rebuild solution form Build menu. publish again. this may solve your problem – MD. RAKIB HASAN Dec 21 '21 at 13:07

3 Answers3

1

This started as a comment that exceeded the character limit...

Hopefully one of these suggestions/strategies go somewhere. Mostly going off a few potential hunches here from previous issues with .NET assemblies not behaving. (Though, please bare in mind that it's been a year or two since I was working on a large C# code base).

(i) Issues with conflicting Nuget repo sources

This is usually if you have a company-specific Nuget repository. I've seen issues happen if there are conflicting packages, versions, etc. between the public Nuget repo (or if even allowed in some cases) and the company's one.

(ii) Issues with Nuget package requesting conflicting dependency versions

I very distinctly remember at one point that I had to manually check that each of my Solution-Wide dependencies were on the same version. I never trust the per-package view since it's incredibly easy to install the more up-to-date, but wrong and conflicting package. In other words, ensure that any packages referenced by EF Core or any other packages that would bring in EF Core are on the same version between projects.

(iii) Your local Nuget package cache may be corrupted or inconsistent

It would not be the first time where I've had to just delete the Nuget caches and just redownload packages. Important: If I recall correctly, this likely may require having to reinstall or repair install .NET Core.

The various default locations for the Nuget caches are detailed on Microsoft's docs here. In case the link breaks, here is the tl;dr:

  • Package Download Cache Windows: %localappdata%\NuGet\v3-cache
    Mac/Linux: ~/.local/share/NuGet/v3-cache
    (Note: can be overwritten by NUGET_HTTP_CACHE_PATH environment variable)

  • Project packages within the solution folder itself.

(iii) Use the debugger's "Modules" window to see which DLLs are loaded, and see which DLL is throwing the exception

This ideally can pin-point which the library or executable that is the culprit.

Hopefully one of these tips may be helpful to determine what the root cause is. Or at least what may be potentially the culprit.

Josh Bowden
  • 5,735
  • 2
  • 25
  • 36
0

I ran exactly in the same issue, since I updated EntityFrameworkCore.Sqlite from 6.0.0 to 6.0.1. The last days I did more or less the options mentioned above. Today I found a (hopefully) final solution which worked for me:

In the Nuget Manager was only Microsoft.EntityFrameCore.Sqlite listed under Installed, not Microsoft.EntityFrameworkCore. So the dependcy seems to be included from the Sqlite package. I added the Microsoft.EntityFrameworkCore. package explicit to my web application and since that the publish folder contains the current version 6.0.1 of this and all further dependencies.

Andi Oz
  • 1
-2

Following step guide to help you solve the problem:

  1. Delete all bin and obj hidden folder from your project (do it on every project in your solution).
  2. Clean the solution.
  3. Rebuild solution.
  4. Publish again.

We have two folders bin obj because the compilation process goes through two steps, compiling and linking. See the below diagram.

enter image description here
⬤ In compiling phase, every code file is compiled into individual compiled units. So if you have two code files, two independent compiled codes will be generated.
⬤ In linking phase, all these compiled code files are linked and compiled into a single unit assembly which can be a DLL or EXE. Ref: Link

MD. RAKIB HASAN
  • 3,670
  • 4
  • 22
  • 35
  • Honestly, I think a 60k rep, c# gold badge holder might know what a bin folder is.. – Caius Jard Dec 22 '21 at 06:40
  • 1
    Some of the text of this answer appears to be copied without attribution from Cody Gray's answer [here](https://stackoverflow.com/questions/5308491/what-are-the-obj-and-bin-folders-created-by-visual-studio-used-for). Other elements of the answer appear to be from Shivprasad Koirala's answer in the same. This sort of tactic doesn't usually go over well; we're like a team and we acknowledge the efforts of our fellow professionals, rather than pass their work off as our own – Caius Jard Dec 22 '21 at 06:43
  • @CaiusJard this answer may search by another developer, that why I add this info... – MD. RAKIB HASAN Dec 22 '21 at 06:47
  • 2
    Suggest this question as a duplicate of that question then, rather than copying its answers here and hiding "attribution" away in a tiny link at the bottom only when called out on it – Caius Jard Dec 22 '21 at 06:55
  • Although it was not necessary to describe to me what the *obj* and *bin* folders are for, I have resolved the issue. And the way I did it was to delete these folders from all projects in my solution. Once resolved, there was no way to delete a question with a bounty. And this is indeed the correct answer. – Jonathan Wood Dec 22 '21 at 18:47
  • For future reference: I'm not sure but I think you get the same result by switching to **Release** and then back to **Debug** configuration. Used to be one of those backdoors too... – Pieterjan Dec 22 '21 at 21:19