CODEWITHSUNDEEP
.net.net-coreazure-web-app-service
Mark
Mark

Reputation: 560

.Net Core 3.x compatibility with .Net Framework 4.7

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?)

Upvotes: 4

Views: 5943

Answers (1)

Ryan Hill
Ryan Hill

Reputation: 1942

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.

Upvotes: 6

Related Questions