重写.NET Core版本后，将一个Azure App Service的代码库切换为另一代码库

本文介绍了重写.NET Core版本后，将一个Azure App Service的代码库切换为另一代码库的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我们在Azure上有一个.NET Core 2.1 Web App作为应用程序服务.我们通过Visual Studio 2017的发布选项将其部署到Azure(尽管它也在Git存储库中).它具有一堆自定义域和Azure提供的所有SSL.

We have a .NET Core 2.1 Web App on Azure as an App Service. We deploy it to Azure via Visual Studio 2017's publish option (though it is also in a Git repo). It has a bunch of custom domains and SSL on all of them provided by Azure.

我们在VS 2019中用.NET Core 3.1编写了Web应用程序的新版本.功能相同，但是是完全从头编写的，而不是尝试升级现有的2.1版本.

We've written a new version of the web app in .NET Core 3.1, in VS 2019. Identical functionality but written from the ground up rather than trying to upgrade the existing 2.1 version.

目前没有在线的暂存版本-我们在本地计算机上进行开发，然后仅在线使用使用相同服务的测试域，但是将环境切换为使用开发数据库和存储区位置等，这是原因之一写一个新的应用程序而不是升级它，而且看起来更干净，而且我看到人们在进行升级时遇到了一些问题...

There's no staging version online as such - instead we develop on local machines and then just use test domains online that use the same service but where the environment is switched to use dev DBs and bucket locations etc, which is one of the reasons to write a new app rather than upgrade it, also, it just seemed cleaner and I saw that people had some issues when doing upgrades...

是否有一种简单的方法可以将新的Web应用程序/代码切换/发布到当前的Azure App Service中，以替换旧的Web应用程序/代码?还是我需要创建一个新的App Service，然后在从旧域中删除所有自定义域，SSL等后，再在其中创建它们?

Is there an easy way to switch/publish the new web app/code into the current Azure App Service, to replace the old one? Or will I need to create a new App Service and then create all the custom domains, SSL etc there after removing them from the old one?

或者我可以切换到git部署，然后将整个新项目推到旧项目上吗?这行得通还是会造成某种灾难?

Or could I perhaps switch to git deployment and push the entire new project in over the old one - would that work or just create some kind of disaster?

推荐答案

将新的应用程序版本推送到您的应用程序服务时，即使它使用的是.NET Core的新版本，通常也没有问题.您必须考虑两件事:

There is usually no issue when pushing a new application version to your app service, even if it uses a new version of .NET Core. You have to consider two things:

• Windows AppService计划:.NET Core 3.1运行时已在全球范围内推广，而SDK尚未(尚未).如有疑问，请使用独立的部署.
• Linux AppService计划:您需要在门户中选择所需的运行时版本.使用例如 Azure管道您可以在发布新版本的同时设置运行时版本.不确定VisualStudio如何处理此问题.

• Windows AppService Plan: .NET Core 3.1 runtime has been rolled out worldwide, while the SDK has not (yet). When in doubt, use self-contained deployment.
• Linux AppService Plan: You need to select the desired runtime version in the portal. Using e.g. Azure Pipelines you can set the runtime version at the same time as you publish the new version. Not sure how VisualStudio handles this.

作为一般建议，您应该遵循使用广告位部署对您的客户影响尽可能小.每个插槽可以具有例如.NET运行时版本不同，因此您可以测试登台插槽中的所有内容.

As a general recommendation, you should follow silents suggestion of using slot deployments to have as little impact for your customers as possible. Each slot can have e.g. a different .NET runtime version, so you can test everything on the staging slots.