11

I have a .NET Core web application which I deploy as an Azure Web App.

This has been working perfectly until last night when I applied the Visual Studio 2017 upgrade (v15.2).

The .net core version was upgraded from 1.1.1 to 1.1.2. When I deploy to Azure the website fails to start with a 502.5 error.

After investigating I can see .NET Core 1.1.2 is not deployed to the Azure image.

I cannot install the new framework to the web app instance (understandably permission is denied on the Program Files directory). I cannot 'downgrade' through the nuget package manager as it reports the version is 'Blocked by the project'. I cannot see a way to define the version of Microsoft.NETCore.App in the csproj file as it seems this is 'automagically' controlled by the root <Project Sdk="Microsoft.NET.Sdk.Web"> element.

I have tried attempting a self contained deployment (shipping the framework with the web app) but can't get this working either.

Short of waiting for the new version to be deployed to Azure (I can't find any information on their schedule for this) does anyone have any ideas on how to get the web app working again?

Is there any way to force it to run under 1.1.1?

ekad
  • 14,436
  • 26
  • 44
  • 46
Steve Jackson
  • 295
  • 4
  • 9
  • 1
    I have the same error since the update of vs2017 to version V15.2... – Geotinc May 11 '17 at 13:49
  • Possible duplicate of [ASP.NET Core web app HTTP Error 502.5 Process Failure on Visual Studio 15.2](http://stackoverflow.com/questions/43902658/asp-net-core-web-app-http-error-502-5-process-failure-on-visual-studio-15-2) – ThisWillDoIt May 11 '17 at 14:48

3 Answers3

14

Update 5/12/2017: we have accelerated the deployment of 1.1.2 and 1.0.5 to App Service and it is now complete. So the workaround below should no longer be needed by anyone.

Original solution

The best workaround is to set this in your .csproj file:

<TargetFramework>netcoreapp1.1.1</TargetFramework>

Instead of it being set to netcoreapp1.1. We will have 1.1.2 deployed to Azure App Service by Tuesday, at which point the workaround won't be necessary.

Note that if if you set it to netcoreapp1.1.1, once 1.1.2 is available it will auto-roll forward to that. So setting it to netcoreapp1.1.1 does not keep you 'stuck' to that version. This is true as long as you use Portable mode (i.e. rely on the framework that's on the OS). If you use standalone and deploy your own framework, then you would be stuck to it (but then you would not have had this issue in the first place and would not have needed to do that!).

David Ebbo
  • 42,443
  • 8
  • 103
  • 117
  • 3
    As much as I like shiny new features and fixes, in the future do you think you can roll out Visual Studio updates *after* their prerequisites? – Edward Brey May 11 '17 at 20:15
  • 5
    @EdwardBrey Definitely, there is some learning to be had here. The problem is that no one realized that simply having the new VS would caused the deployed bits to target the new version, even though the user's files are exactly the same. So yes, we messed up, and we'll make sure to avoid this situation next time. – David Ebbo May 11 '17 at 21:06
  • 2
    Thanks for replying here, and that you acknowledge that this is not optimal. – Boland May 12 '17 at 09:07
  • Andrew Hill commented on the [bug report](https://developercommunity.visualstudio.com/content/problem/54605/aspnet-core-http-error-5025-process-failure-error.html) that specifying `netcoreapp1.1.1` "will lock the project into running on a version of the runtime with known security vulnerabilities". This seems to indicate that auto-roll forward won't work. Could you two sync up and let us know what to expect? – Edward Brey May 12 '17 at 17:00
  • @EdwardBrey Yes, I will connect with Andrew Hall and we will clarify which way it it. – David Ebbo May 12 '17 at 17:29
  • Related discussion on https://github.com/aspnet/IISIntegration/issues/368 – David Ebbo May 12 '17 at 17:35
  • @EdwardBrey I talked to Andrew and others. I've clarified my answer with more subtleties about that point. – David Ebbo May 12 '17 at 23:44
  • 1
    @DavidEbbo I still got this error, but based on your updated answer there there should be no need of setting netcoreapp1.1.1 as targetFramework when using AspNetCore 1.1.2 ? Am I correct? Are there other settings that are required to get things running now? – Larsi Jun 09 '17 at 07:14
  • 1
    @Larsi you are very likely running into something different, even if error looks similar. 1.1.2 is deployed everywhere, so this issue no longer exist. Please start a new question with details on your situation. Feel free to link it from here for context. – David Ebbo Jun 09 '17 at 13:11
  • @Larsi Got this error too after updating to 1.1.2. and deploying to azure. The solution for me was to delete the contents of wwwroot on azure. – martinoss Jul 06 '17 at 13:17
  • @DavidEbbo I notice that I get the OP's error unless I explicitly reference `netcoreapp1.1.2` (rather than just netcoreapp1.1) when deploying to azure. When you say "it will auto-roll forward to that" do you mean that using 1.1 is supposed to automatically select the most current minor version? If so, I don't see that behaviour.... – mikebridge Jul 08 '17 at 07:05
  • @mikebridge 1.1 should work, and OP's error was specific to when Azure didn't have 1.1.2. So I think you're dealing with something else. Can you start separate question with full details, and link to it from here? Thanks. – David Ebbo Jul 08 '17 at 08:07
2

We are having the same issue after the Visual Studio 2017 Update.

A workaround is to edit the web.config for your site in Kudu after it has been deployed.

Add --fx-version 1.1.1 at the start of the arguments value for the aspNetCore entry under system.webServer

e.g <aspNetCore processPath="%LAUNCHER_PATH%" arguments="--fx-version 1.1.1 PATH_TO_DLL" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"/>

Gregg_1987
  • 433
  • 7
  • 19
  • See my answer for a simpler workaround that doesn't require hacking things in Kudu post deployment. – David Ebbo May 11 '17 at 19:53
  • 1
    Unfortunately, this was the only solution that worked for me (packaged netcoreapp2.1 project running on a box with 2.2.1 available). The `TargetFramework` version was already correct, adding this argument solved the runtime issue for us. – Ian Yates Jan 11 '19 at 15:39
1

Until they get around to deploying 1.1.2 to the web app images I managed to fix this by forcing the project to reference Microsoft.NETCore.App 1.1.1

Edit the csproj file:

<ItemGroup> <PackageReference Update="Microsoft.NETCore.App" Version="1.1.1" /> <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.0.0" /> <PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" /> ... etc

Steve Jackson
  • 295
  • 4
  • 9
  • That is not a recommended workaround. Instead, just change `TargetFramework` per my answer. – David Ebbo May 11 '17 at 19:52
  • Thank you @DavidEbbo. What is the correlation between the nuget references and the TargetFramework? It's a bit confusing. I've updated all packages to the latest versions, and also updated targetframework to 1.1.2. Due to the Azure bug, I'm reverting that back to 1.1.1. However I'm leaving NuGet as is. – Boland May 12 '17 at 09:08