2

I am running a custom EntityFrameworkCore version which has some added functionality which I require. Since Thursday 2019/07/25 I am getting MissingMethodException on 3 of my 4 app service plans: dev, stage and production. The test, stage, and production environment are in sync and contain the same exact code. It is therefore very odd that the test environment still works. I also have integration tests set up in the Azure Devops pipeline. The pipeline performs the following tasks: use dotnet, dotnet restore, dotnet build, dotnet test, dotnet publish. And all tests succeed. It is only on the app service that the same requests do not function.

  1. No publish was done to the test, stage, and production environment since 2019/06/28.
  2. The test environment has the same code as the stage, and production environment and functions properly.
  3. Only as recent as 2019/07/25 it stopped working on dev, stage, and production. Before that: everything fine.
  4. The end-to-end integration tests all succeed on the on-premise build server using the Azure Devops pipeline.
  5. It's cliché but, it works locally.

This is very scary that something which functions properly for a month suddenly overnight stops functioning entirely. Without any change in code.

I read that the MissingMethodException points to a DLL problem (System.MissingMethodException: Method not found?). The MissingMethodException occurs in the custom code so a DLL problem seems logical, but I cannot figure out why then does everything still work on the test environment and why did it work before! How can I properly diagnose this?

Vqf5mG96cSTT
  • 2,561
  • 3
  • 22
  • 41
  • Which versions of Core, EF and ASP.NET? Where you using 3.0/preview? – H H Jul 28 '19 at 11:48
  • @HenkHolterman Thanks for your reply, hopefully I added the information you wanted. – Vqf5mG96cSTT Jul 28 '19 at 13:10
  • Yes, this is useful. Maybe you could use Kudu to inspect what is installed on the server, keep en eye on the timestamps of the DLLs involved. It is rather suspicious because Core3/preview7 was rolled out around that day. – H H Jul 28 '19 at 15:41
  • As a workaround, first update/consolidate with the latest 2.2 packages. Then deploy that to staging. Other option would be to deploy as self-contained. – H H Jul 28 '19 at 15:42
  • But it is worth opening an issue on GitHub EF or with Azure. When you can be sure that your 'Custom EF' is not at fault. – H H Jul 28 '19 at 15:42
  • @HenkHolterman Thank you for your reply. Deploying as self-contained works, so at the very least I have one workaround already functioning. But I'm unfamiliar why it works, which to me is the most important element. Do you have any idea? Is deploying as self-contained the recommended approach? – Vqf5mG96cSTT Jul 28 '19 at 15:59
  • Well, here is [a similar issue a few year ago](https://stackoverflow.com/a/12819524/60761). Something was updated that should have been backw compatible but it wasn't. – H H Jul 28 '19 at 16:12

1 Answers1

1

Apparently .NET Core has a dependency on EntityFrameworkCore. Because of this dependency installing a .NET Core SDK comes supplied with its own Microsoft.EntityFrameworkCore DLLs. This isn't a problem as long as my custom EntityFrameworkCore DLLs are of a higher version than the ones installed by the SDK. But the versioning they apply does not seem to be the versioning of EntityFrameworkCore but rather that of the runtime used. Last week behind the scenes an update happened to the API apps. This meant that the 2.2.6 runtime was installed. This runtime has EntityFrameworkCore DLLs with a higher version number than my custom one. Because of this a sudden switch of DLLs used by the application happened and a custom method was no longer found which lead to the MissingMethodException.

I diagnosed the problem after installing the latest .NET SDK. This caused the latest runtime to be installed and my solution to behave in the same way locally as the ones deployed. I opened the Modules window (Debug -> Windows -> Modules) and then realised what was happening.

This means I no longer need self-contained deployments, but it's probably worth it to look into it nonetheless to avoid breaking changes due to random updates.

Vqf5mG96cSTT
  • 2,561
  • 3
  • 22
  • 41