HTTP Error 502.5 - Microsoft.AspNetCore.Antiforgery.dll

[alaminut]

I've deployed my Asp.Net Core 2.0 app to a new Azure Web App from Visual Studio 2017 publish tool.

When I open up my application it gives me 502.5 error and does not start, I enabled logging and found out this error is logged:

Error:
An assembly specified in the application dependencies manifest (Epiverita.UI.deps.json) was not found:
package: 'Microsoft.AspNetCore.Antiforgery', version: '2.0.1'
path: 'lib/netstandard2.0/Microsoft.AspNetCore.Antiforgery.dll'

This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
aspnetcore-store-2.0.3.xml

Application works perfectly fine on local development environment, and just in case I added above dependency as a seperate NuGet package - it is normally included in Microsoft.AspNetCore.All package - but I still get this error.

How can I solve this?

---

Resolution

EDIT by @natemcmaster May 18, 2018: this error happens when deploying to a machine that is missing the ASP.NET Core package runtime store. Please ensure your target machine has been updated to the latest version of ASP.NET Core 2.0.x. See https://www.microsoft.com/net/download/all for downloads. If you are still having issues, please open a new bug on https://github.com/aspnet/Home.

[dcarr42]

2.0.3 has only been published for a day....kudo in and attempt a dotnet restore.

[alaminut]

Sorry I didn't understand what you mean by restore?

[dcarr42]

If you attempt a dotnet restore/build up in Azure you might be able to isolate the issue.

[dcarr42]

dotnet/aspnetcore#2254

[MitchellNZ]

Running into the same issue myself..

Error I'm getting from Kudu when trying to manually dotnet run is:

Error:
  An assembly specified in the application dependencies manifest (APP_NAME.deps.json) was not found:
    package: 'Microsoft.AspNetCore.ApplicationInsights.HostingStartup', version: '2.0.1'
    path: 'lib/netcoreapp2.0/Microsoft.AspNetCore.ApplicationInsights.HostingStartup.dll'

  This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
    aspnetcore-store-2.0.3.xml

I am using the Microsfot.AspNetCore.All package (which appears to include this package mentioned above).
I have also tried manually including the package.. But no luck.

I am out of ideas now.. if anyone could point me in the right direction, would be much appreciated.
Thanks!

[robpearson]

I hit this as well and I fixed it by following the instructions in this comment.

The problem is the ASP.NET web app is using the host server package store and the Azure one hasn't been updated as needed. The solution is to add <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest> to your csjproj files so the dotnet publish bundles all the required files. Mine now looks like this:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
  </PropertyGroup>
...

More info here.

I build my web apps w/ TeamCity and ship w/ Octopus Deploy and that's the only change I needed.

[alaminut]

Fixed this issue with @robpearson's suggested solution. Running dotnet restore on Kudu did not solve it. Any ETA on when will Azure package store be updated?

[sebastianbk]

I am still having this issue when publishing to Azure Web Apps. I followed @robpearson's advice and adding the PublishWithAspNetCoreTargetManifest property and setting it to false. However, when navigating to my Azure Web App, I still see the 502.5 error. What else could be wrong?

Here is a dump of my csproj file: https://pastebin.com/1CfNKcRb

@Eilon, can you maybe help out on this one? It's pretty critical to our business.

[Eilon]

@muratg - do you know the status of getting Azure apps working with this? Also cc @JunTaoLuo in case you know about this.

[muratg]

@sebastianbk What does your publish output look like when you set that property and do a restore? It should have a lot of assemblies with the property set to false.

Also, what's your deployment mechanism to App Service?

[sebastianbk]

Hi @muratg. Here is the output of dotnet publish -c Release: https://pastebin.com/FJS5z8hP

I have both tried using Web Deploy from Visual Studio (15.4.4) as well as dragging and dropping in all the files via Kudu.

[muratg]

Files seem to be present in your publish output. @JunTaoLuo Any thoughts?

[JunTaoLuo]

@sebastianbk would you be able to share your logs with us? You can turn it on by modifying the web.config by setting stdoutLogEnabled to true and creating the logs directory adjacent to your application dll

<aspNetCore processPath="dotnet" arguments=".\App.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />

[Tratcher]

Azure/app-service-announcements#61

[sebastianbk]

@JunTaoLuo, here is what I see in my event log (via Kudu):

<Event>
    <System>
        <Provider Name="IIS AspNetCore Module"/>
        <EventID>1000</EventID>
        <Level>1</Level>
        <Task>0</Task>
        <Keywords>Keywords</Keywords>
        <TimeCreated SystemTime="2017-11-17T07:37:18Z"/>
        <EventRecordID>815005312</EventRecordID>
        <Channel>Application</Channel>
        <Computer>RD0003FF30E033</Computer>
        <Security/>
    </System>
    <EventData>
        <Data>Application 'MACHINE/WEBROOT/APPHOST/VRINNOCLOUD__3778' with physical root 'D:\home\site\wwwroot\' failed to start process with commandline 'dotnet .\Sensomind.Web.dll', ErrorCode = '0x80004005 : 80008083.</Data>
    </EventData>
</Event>

However, I am not getting any logs in my logs folder (placed in wwwroot along with my app DLL) after setting stdoutLogEnabled to true. I tried republishing (both Debug and Release) as well as restarting the site from the management portal. Is there something obvious here that I am doing wrong?

[JunTaoLuo]

@sebastianbk from what I gather, you have updated to the 2.0.3 patch? It looks like the deployment hasn't completed yet so running a platform dependent app will not work at the moment. For now if you want to deploy, you will need to do a standalone publish. Run a command like dotnet publish -c Release -r <RID> where you choose an appropriate RID. That will publish the runtime along with your app during deployment. Note that I've seen issues in the past where this produces too many files in the publish output and Kudu fails to copy all files over to azure; I believe publishing from VS worked though.

[mrkemaltas]

@alaminut
The source of this problem is that the dotnet version on your local computer and the dotnet version on the server are different
Example
Server 2.0.2
Local 2.0.3

[tmakin]

I think I have just run into this with the release of the 2.0.6 runtime. For anyone else struggling to work out exactly what packages are installed on App Service you can inspect the contents of the package store via kudu D:\Program Files (x86)\dotnet\store\x86\netcoreapp2.0

For example:

D:\Program Files (x86)\dotnet\store\x86\netcoreapp2.0\microsoft.aspnetcore.antiforgery>ls
2.0.0
2.0.1

So I can clearly see that my host VM is not up to date yet, as my project references antiforgery 2.0.2.

[tim-elvidge]

Well I updated two local IIS installations with DotNetCore.2.0.6-WindowsHosting.exe and encountered the same issue. Even after repairing and reinstalling the 2.0.2 directories in the store at C:\Program Files\dotnet\store\x64\netcoreapp2.0 were missing - luckily was able to merge them from my development machine and everything started working again.

Did not enjoy the lost hour and the WTF experience.

[muratg]

@tmakin I think the patch release is still being rolled out on Azure. What datacenter are you deployed to?

@tim-elvidge I'm sorry for the experience. There was an issue with DotNetCore.2.0.6-WindowsHosting.exe that was fixed just this morning. It should be good now.

edit: The note about the updated installer is here: dotnet/core#1341 (comment).

[tmakin]

@muratg I'm in uk south. The update has not made it there yet.

[Eilon]

From @preetikr in dotnet/core#1341 (comment):

Thanks, for your patience on this. The issue with the DotNetCore 2.0.6 Hosting bundle is now resolved and you can download the updated file from here. Please note as part of the refresh we have changed the file name from DotNetCore.2.0.6-WindowsHosting.exe to DotNetCore.2.0.6-1-WindowsHosting.exe.

[tmakin]

@muratg Still no sign of the update on my uk south instance. Is there are recommended procedure for manual update via kudu? or do I just need to sit tight and wait?

However, the PublishWithAspNetCoreTargetManifest workaround works so I'll stick with that for now.

[kieronlanning]

Getting a little fed up of this.

Same problem this-morning (UK South too).

Complaining about .NET Core 2.1-preview something or other having missing dependencies.

I've never touched .NET Core 2.1. There was some extension installed in App Services that was updated to a preview version.

Removed that. Now I have this issue about missing AntiForgeryToken in the 2.0.6 store.

It shouldn't be this hard.

[kinetiq]

It was working fine in US East, but then it actually stopped working... The workaround got me going.

I was in the middle of troubleshooting an unrelated issue, so this threw me way off track.

[muratg]

Hey folks, Azure rollout should be complete by now: Azure/app-service-announcements#92

If you are still having issues, please let us know.

[kieronlanning]

@muratg The issue isn't if the rollout has finished or not, the issue is one of down time.

I'm not sure how, as the team responsible, anyone can justify any downtime over a preview upgrade. Or any upgrade for that matter in a way that leaves us usually clueless as to what in the hell is happening.

[evil-shrike]

hi.
Is this the same issue that people massively experiencing here - https://github.com/dotnet/coreclr/issues/13542 ?
Could someone please comment on the status: what actual problem is and what should we do in 2.0 project?

ps:
I easily reproduced the issue when I build and run a sample app in Docker:

FROM microsoft/aspnetcore-build:2.0 AS build-env

for a project with reference:

    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.6" />

[VictorioBerra]

@kieronlanning Or you could just roll Microsoft.AspNetCore.All back from 2.0.8 to 2.0.7.

[kieronlanning]

@VictorioBerra That release is a security update to prevent a DoS attack based on the processing of XML documents.

So I wouldn't recommended it, but it's your choice of course.

[natemcmaster]

Just updated All metapackage to 2.0.8 today and getting this issue on our IS server with package: 'Microsoft.AspNetCore.Antiforgery', version: '2.0.3'. I installed Microsoft .NET Core 2.0.7 - Windows Server Hosting Bundle and this did not fix my issue.

This should be fixed by downloading this update to the Windows Server Hosting bundle. The bundled was updated yesterday to include the 2.0.8 metapackage (and its dependencies). See https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.1.200-sdk-download.md#aspnet-runtime-core-package-store for additional downloads.

[dhabierre]

Fixed with:

• DotNetCore.2.0.7-WindowsHosting.exe
• AspNetCore.2.0.8.RuntimePackageStore_x64.exe (or AspNetCore.2.0.8.RuntimePackageStore_x86.exe)

Source

[sguryev]

Have the same issue #476 (comment)
Could you please provide some estimation when it will be fixed on Azure App Services?

BTW, I have 3 app services (2 have been built from API template and 1 from MVC template in VS2017) and only 2 API services shows 502 error now. MVC application (which is also has been updated to metapackage 2.0.8) works as expected.

[bradleypatton]

Also ran into the same issue and wasted this morning tracking it down. I tried false per one of the earlier posts and this didn't change anything.

Only solution for now on Azure seems to be rolling back to AspNetCore 2.0.7.

[sguryev]

@bradleypatton just tried the solution from #476 (comment) and it works fro me.
Please make sure that you have pasted it to the right place. You can find it in the DUMP from this comment: #476 (comment) or this #476 (comment)

[VictorioBerra]

Upon installing the new bundle provided by #476 (comment) on 5/8 I now see microsoft.aspnetcore.antiforgery 2.0.3 in my package store (confirming the install of runtime 2.0.8)

I have yet to deploy my app with the latest metapackage but I am almost certain it would work now.

As for anyone slapping <PublishWithAspNetCoreTargetManifest> into their csproj files I urge you to first read what that does and to also understand why you are even here and having this issue in the first place.

[sguryev]

I'm seeing the Microsoft.AspNetCore.Antiforgery 2.0.3 in the Microsoft.AspNetCore.All 2.0.8 as well. But issue is still presented in the Azure. I think that problem in the latest Runtime which has not been updated yet.

I'm seeing similar error like here: #476 (comment) but with Antiforgery 2.0.3 and aspnetcore-store-2.0.8.xml from Kudo debug console running dotnet <projectname>.dll command

[VictorioBerra]

Yeah that's a big deal, it seems that they have difficulty reacting and moving Azure when vulnerabilities are found which is troubling. The speed at which the vuln was patched and fixed was nice, metapackage was ready almost immediately. But that does not help when we have to wait for hosting environment bundles, or managed hosting environments to catch up unless we disable features that are enabled by default when you create a new application. We need to eliminate situations where users update a nuget package only to learn after a deployment their app will not start unless they add a flag to their project files. Most people myself included had no idea what the dotnet runtime package store was and more importantly that by default our apps are using packages are deployed against packages stored on the target environment.

https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-store#aspnet-core-implicit-store

[natemcmaster]

I am working with the Azure App Services team to get the 2.0.8 package store installed. We expect to have this available next week. We're also working with the Azure App Services to reduce the gap between rollout to NuGet.org and Azure App Services.

For those concerned about exposure to this vulnerability in System.Security.Cryptography.Xml, you can workaround and still run on the latest patches by disabling the runtime package store trimming. Set this variable in your project. This will instruct the SDK to copy aspnet binaries into your publish output instead of expecting them to be installed in your target environment. This should be temporary, and can be removed once Azure App Services has been updated.

<PropertyGroup>
  <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>

As a side note: we recognize that resolving the mismatch between NuGet and the runtime store has been especially painful. This was one of the motivations for changing ASP.NET Core in 2.1 to be a shared framework runtime, instead of a runtime package store. That means -- starting in 2.1 -- applications targeting Microsoft.AspNetCore.App will get automatically rolled forward into security patches as soon as they are available, without you needing to re-build and re-deploy your application. See aspnet/Announcements#287 for more details and discussion on this topic.

[Luis-Palacios]

I'm on the same boat here, Updated to 2.0.8 very happy in local when we deployed to azure kabum 502.5 my error on kudu is:

  An assembly specified in the application dependencies manifest (Lido.WebApp.deps.json) was not found:
    package: 'Microsoft.AspNetCore.Antiforgery', version: '2.0.3'
    path: 'lib/netstandard2.0/Microsoft.AspNetCore.Antiforgery.dll'

  This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
    aspnetcore-store-2.0.8.xml

Definitly waiting on solution to the mismatch between runtimes @natemcmaster

[davidebbo]

@Luis-Palacios that's expected as it hasn't been deployed to App Service yet. Actually, it is in one region so far: West US 2. Can you give it a quick try there is a test site to help validate?

Please follow Azure/app-service-announcements#107 as well

[Luis-Palacios]

Sure, I'll create one App Service on that region and test the release I have on 2.0.8. I'll let you know

[Luis-Palacios]

I can confirm the App with 2.0.8 works on the App service that is on West US 2 @davidebbo

[davidebbo]

Thanks @Luis-Palacios, this is helpful to the team to have some user validation in addition to our own. Much appreciated!

It should be everywhere by Tuesday if we don't hit any issues (same for 2.1 RC1).

[NikolaosWakem]

It would be great is VS2017 could tell you in the publish "You are publishing an application that targets a version that is not on azure - don't waste your time' or "The app you are publishing targets a latter version of the framework than is on Azure - we will execute this publish including 2.0.8"

https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-store#aspnet-core-implicit-store

[davidebbo]

@NikolaosWakem @Luis-Palacios 2.0.8 is now available on App Service.

[MattJeanes]

Hello, since dotnet/AspNetCore.Docs#6281 was (rightly) locked, I wanted to re-iterate my point from over there:

This has just caused us a world of pain too 😢

The bundle download page currently links to an older version

https://www.microsoft.com/net/download/thank-you/dotnet-runtime-2.0.7-windows-hosting-bundle-installer ->https://download.microsoft.com/download/A/9/F/A9F8872C-48B2-41DB-8AAD-D5908D988592/DotNetCore.2.0.7-WindowsHosting.exe

When it looks like it should be going to your new link https://download.microsoft.com/download/E/F/7/EF7302FE-4F84-4529-9E3A-893450F76501/DotNetCore.2.0.7-WindowsHosting.exe

After installing that new link, the 2.0.3 package installed and everything worked. Looks like you guys might need to update that download link.

I think this needs to be addressed more globally though, as I'm sure I won't be the last one to be hit by something like this. Re-publishing a newer version of the Windows Hosting package with newer binaries under the same version number doesn't seem right.

I appreciate that the actual net core runtime hasn't changed so you wouldn't want to change it to 2.0.8 but I do think something better needs to be done to prevent this confusion, even if it's just a better error message with more clues.

Thanks! 😄

[davidebbo]

This is a big thread that it seems has many topics happening in parallel. My previous comment relates exclusively to the deployment to App Service, and the best place to discuss that further is Azure/app-service-announcements-discussions#47.

Any anything else, I'll let the ASP.NET folks jump in.

[Memnarch]

Just stumbled uppon this issue myself. I published a selfcontained app for Ubuntu(Windows works fine).
using this cli:
dotnet publish -c Release -r ubuntu.14.04-x64
or
dotnet publish -c Release -r ubuntu-x64

ANd i don't understand why it tries to look in /lib/*
All files seem to be in the publish subfolder

[natemcmaster]

Can you open a separate issue for that on https://github.com/aspnet/Home? The original issue should have been fixed, and the behavior you are seeing may be unrelated.

[Memnarch]

Ok

[maria-lau]

Hi there,

I attempted to deploy a .NET app from Visual Studio to the Google Cloud App Engine (flex) and repeatedly got the error below:

"An assembly specified in the application dependencies manifest (.deps.json) was not found:
package: 'Microsoft.AspNetCore.Antiforgery', version: '2.0.3'
path: 'lib/netstandard2.0/Microsoft.AspNetCore.Antiforgery.dll'

This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
aspnetcore-store-2.0.8.xml"

I've downloaded the newest .NET Core SDK, and the runtime file you linked above. And I can see the antiforgery dll file here at this path:

C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.antiforgery\2.0.3\lib\netstandard2.0\Microsoft.AspNetCore.Antiforgery.dll

Since I'm using Google Cloud App Engine (Flex) and not Azure, I'm not sure if all the comments above pertain to me? I'm relatively new to this, so I'd appreciate any help I can get!

Oh also, using the following line of code in my .csproj
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
fixes the error so that I'm able to deploy to the cloud, but I've read that it's not a good solution, so I'd like to try to fix it without using that line of code.

[bfren]

MattJeanes is spot on - from the thread he references I re-downloaded the 2.0.7 hosting package twice, to no avail - but using his link works. The primary download link needs to be updated to the correct package before this becomes a bigger problem.

[natemcmaster]

Since I'm using Google Cloud App Engine (Flex) and not Azure, I'm not sure if all the comments above pertain to me?

@maria-lau I'm not sure how Google Cloud hosts your apps, but if you're seeing this error, there is a good chance Google hasn't updated their shared hosting environments to include the ASP.NET Core 2.0.8 runtime package store yet.

I've pinged our marketing team again to update the links on our download page. These are the proper links for the ASP.NET Core 2.0.8 (May 2018 patch) package runtime store.

• Windows Server Hosting Bundle
• Windows x64 ASP.NET Core Runtime Installer
• Windows x86 ASP.NET Core Runtime Installer
• Windows x64 ASP.NET Core Runtime Binaries
• Windows x86 ASP.NET Core Runtime Binaries
• Linux x64 ASP.NET Core Runtime Binaries
• macOS x64 ASP.NET Core Runtime Binaries

If you are using yum/apt on Linux, install the dotnet-hosting-2.0.8 package.

Also FYI - I'm going to lock this thread as the original issue (opened in November) has been resolved. If you are still encountering issues with the package runtime store, please open a new bug on https://github.com/aspnet/Home