4

I have a Visual Studio Azure App Service project that targets .Net Core 3.0. When I deploy it to Azure, without me specifying a Stack, the Stack ends up .Net V4.7.

This post asks a similar question: https://social.msdn.microsoft.com/Forums/en-US/a4040bf9-2ba0-42c6-a242-87febf7a5e6d/select-net-core-22-as-technology-stack?forum=windowsazurewebsitespreview The answer says "The .NET Core SDK 32-bit binaries are normally included with Windows app services. Therefore, there is no need to explicitly select .NET Core as the version". In other words: As it is Windows, there is no need to specify a .Net Core target. The implication is that because it is Windows, it'll just work.

This post also asks a similar question: Azure webapp: Stack settings The answer says "after initial web app creation, there isn’t a need to identify that an app is a .NET Core app anymore because the .NET Core bits are already installed on the underlying worker". The implication is also that because it is Windows, it'll just work.

Both seem to contradict this Microsoft reference: https://learn.microsoft.com/en-us/dotnet/standard/net-standard

According to that, .Net Core 3.0 is NOT compatible with .Net Framework of any version. More formally, .Net Standard 2.1 is incorporated in .Net Core 3.0 but NO .Net framework version. Yet, in Azure, my App Service actually works.

Question: Is the reason that it works because although I have specified .Net Core 3.0 as the target in Visual Studio, I'm not actually using any .Net Core 3.0-specific code and therefore, I've been lucky that it works? (IOW, if I were to do something .Net Core 3.0-specific, it would break because the runtime stack would no longer support it?)

Mark
  • 480
  • 1
  • 5
  • 18
  • I've noticed this too. I think the issue is simply that the Azure UI hasn't been updated to support selecting Core, but the actual backend fully supports Core. – Ian Kemp Mar 26 '20 at 17:27
  • Yes indeed - I am wondering if it's a GUI bug or obsolescence. If change the stack in the GUI, what doesn't change is: a) the deployment json; b) the output of 'dotnet --info' and c) the web.config. I'm left wondering, therefore, what difference that GUI option actually makes. – Mark Mar 26 '20 at 17:48
  • 1
    My guess is that the setting simply isn't relevant for Core apps, they just haven't figured out how to represent this in the UI. – Ian Kemp Mar 26 '20 at 19:27
  • I don't think so. I have tested what you describe. And search document about it，and find a post which tell me，~~.Net 4.7 is a new version of .Net Framework which supports .Net Standard 1.6 too, so it would be able to interact with a .Net Core apps.~~ – Jason Pan Mar 27 '20 at 04:49
  • @Jason .Net Framework 4.7 support .Net Standard 2.0 as per the final link in my OP. But whilst Framework 4.7 supports Standard 2.0, it is not necessarily true that Standard 2.0 supports Framework 4.7. Similarly for .Net Cores: you cannot conclude (according to the link I referenced above) that .Net Framework 4.7 is guaranteed to support .Net Core 3.0, though I admit it is likely. Which is the point of my question: have I just been lucky? – Mark Mar 27 '20 at 19:34
  • 1
    @Ian Kemp - yes, that it what I'm thinking: if it is targeted to Core 3.0 it will work on all platforms, making the Stack setting obsolete. – Mark Mar 27 '20 at 19:40

1 Answers1

6

The reason it works is because Azure App Service is deployed with .NET Framework as part of the Windows OS with .NET Core SDKs and runtimes installed. You can create a basic windows app service plan, create a web app tied to that plan and run dotnet --info inside the kudu console. It's exactly the same as installing .NET Core SDK and runtimes on your local Windows dev box. In addition, we are working to get the .NET 3.x SDKs and runtimes on Windows App Services. If you need those binaries, you can use Azure Pipelines to install those SDKs.

enter image description here

Therefore, you can think of the stack option as a guidance check to let you know what frameworks are available on the app service without pushing framework dependencies. E.g., if .NET Core 3.0 is available then you can push a .NET Core 3.0 app framework dependent rather than self-contained. If it's not there, then you know for that region you're planning your app to be in, you'll have to publish as self-contained as the framework hasn't been rolled out yet.

You've been lucky because .NET Core rollout started 2019 Q4. Had your csproj targeted 3.1, I'm willing to bet you wouldn't get quite so lucky :) as 3.1 has been deployed to North Central and West US 2 as 4/8/2020.

Ryan Hill
  • 1,821
  • 2
  • 8
  • 21
  • Thanks Ryan, but that is repeats the two "answers" in the OP, both saying "don't worry about it - all the bits you need are already present". But, the GUI says I'll be using Framework 4.7, and it gives me other options, implying that if I select one option, I don't get the others. I think what you are saying is that I can actually ignore the Framework 4.7 option because "trust me, it'll just work". If so, I think Ian Kemp's answer is actually the right one: "the setting simply isn't relevant for Core apps, they just haven't figured out how to represent this in the UI". – Mark Apr 07 '20 at 23:17
  • Thanks for the feedback @Mark, I've edited my answer. – Ryan Hill Apr 08 '20 at 16:42
  • Awesome, @Ryan Hill - that was the confirmation I was looking for. Many thanks. Mark – Mark Apr 09 '20 at 17:07