.Net Core 3.x 与 .Net Framework 4.7 的兼容性 [英] .Net Core 3.x compatibility with .Net Framework 4.7

问题描述

我有一个面向 .Net Core 3.0 的 Visual Studio Azure 应用服务项目.当我将它部署到 Azure 时，没有指定 Stack，Stack 最终会变成 .Net V4.7.

这篇文章提出了一个类似的问题:

因此，您可以将堆栈选项视为指导检查，让您了解应用服务上有哪些框架可用，而无需推送框架依赖项.例如，如果 .NET Core 3.0 可用，那么您可以推送 .NET Core 3.0 应用程序框架依赖而不是自包含.如果它不存在，那么您就知道您计划应用程序所在的区域，您必须发布自包含的框架，因为该框架尚未推出.

你很幸运，因为 .NET Core 于 2019 年第 4 季度推出.如果您的 csproj 以 3.1 为目标，我敢打赌您不会这么幸运:) 因为 3.1 已于 2020 年 4 月 8 日部署到美国中北部和西部 2.

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://docs.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?)

解决方案

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.

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.

这篇关于.Net Core 3.x 与 .Net Framework 4.7 的兼容性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！