. Net Core 3.x совместимость с. Net Framework 4.7

Question

У меня есть проект службы приложений Visual Studio Azure, предназначенный для Net Core 3.0. Когда я разверну его в Azure, без указания стека, стек заканчивается. Net V4.7.

В этом посте задается аналогичный вопрос: https://social.msdn.microsoft.com/Forums/en-US/a4040bf9-2ba0-42c6-a242-87febf7a5e6d/select-net-core-22-as-technology-stack?forum=windowsazurewebsitespreview В ответе говорится: «32-разрядные двоичные файлы. NET Core SDK обычно включаются в Windows службы приложений. Поэтому нет необходимости явно выбирать. NET Core в качестве версии». Другими словами: поскольку это Windows, нет необходимости указывать. Net Основная цель. Подразумевается, что, поскольку это Windows, оно будет просто работать.

В этом посте также задается аналогичный вопрос: Azure webapp: настройки стека Ответ говорит: «после начальной При создании веб-приложения больше нет необходимости определять, что приложение является. NET Базовым приложением, потому что. NET Базовые биты уже установлены на базовом работнике ". Подразумевается также, что, поскольку это Windows, оно будет просто работать.

Кажется, что оба противоречат этой ссылке Microsoft: https://docs.microsoft.com/en-us/dotnet/standard/net-standard

В соответствии с этим ,. Net Core 3.0 НЕ совместим с. Net Framework любой версии. Более формально. Net Стандарт 2.1 включен в. Net Core 3.0, но версия платформы №. 1040 *. Тем не менее, в Azure моя служба приложений фактически работает.

Вопрос: причина в том, что она работает, потому что хотя я указал. Net Core 3.0 в качестве цели в Visual Studio, я на самом деле не являюсь с использованием any. Net Core 3.0-speci c code и, следовательно, мне повезло, что он работает? (IOW, если бы я что-то сделал. Net Core 3.0-speci c, он сломался бы, потому что стек времени выполнения больше не поддерживал бы это?)

Answer 1

Причина, по которой это работает, заключается в том, что Azure Служба приложений развернута с NET Framework как часть ОС Windows с NET Core SDK и установленными средами выполнения. Вы можете создать базовый c windows план обслуживания приложения, создать веб-приложение, привязанное к этому плану, и запустить dotnet --info в консоли kudu. Это то же самое, что и установка. NET Core SDK и среды выполнения на вашем локальном Windows устройстве. Кроме того, мы работаем над получением. NET 3.x SDK и сред выполнения для Windows Служб приложений. Если вам нужны эти двоичные файлы, вы можете использовать Azure Pipelines для установки этих SDK.

Поэтому вы можете рассматривать вариант стека как проверка руководства, позволяющая узнать, какие платформы доступны в сервисе приложения, не выдвигая зависимости инфраструктуры. Например, если. NET Core 3.0 доступен, то вы можете сделать пул sh a. NET Core 3.0 каркасом приложения зависимым, а не автономным. Если его там нет, то вы знаете, что для того региона, в котором вы планируете разместить свое приложение, вам придется опубликовать sh настолько автономным, поскольку фреймворк еще не развернут.

Вам повезло, потому что . NET Начало развертывания ядра 2019 Q4 . Если бы ваш csproj был нацелен на 3.1, я готов поспорить, что вам не повезет :), так как 3.1 была развернута в Северной, Центральной и Западной США 2 как 4/8/2020.