应用错误收集

尝试在本地和门户中将Azure Functions设置为稳定版本1.0.14或1.0.13

您提到的

1.0.14 or 1.0.13是SDK版本（当前为1.0.19），用于构建我们的功能项目。当然，我们无法在门户上设置SDK版本，因为在将预编译的代码发布到Azure之前，构建已经完成。如果我们使用浏览器进行开发，则构建过程和SDK版本（最新版本）将在Azure的控制下。

我设法通过将版本更改为beta来纠正此问题。没有错误。

您可能已经在本地创建了v2函数，因此该函数取决于Beta运行时。并且您指定了错误的1.x版本，例如1.0.14，因此使用1.0.11959。我们可以看到500错误是由运行时间不匹配导致的，您已对其进行了更正。如果您打算使用v2函数（.net标准），那么到目前为止，没有任何故障。

以及有关函数运行时版本的更多信息。

函数运行时版本

有两个主要版本：.x for .Net Framework和2.x for .Net Standard。

语法

主要版本：~1适用于1.x，~2适用于2.x。通过这种格式，Azure上的功能应用程序在可用时会自动更新为新的运行时次要版本。
次要版本1.x：1.0.11959； 2.x：2.0.11961-alpha，2.0.12050-alpha。（所有版本现在都可用）。在我们明确更改它之前，Azure上的功能应用程序会保留在该版本上。

在哪里找到

配置

我们需要更改运行时的两种情况。

主要版本更改。〜1至〜2或相反。

如果应用中有功能，我们可能会在下面看到提示。

主要版本升级可能会对语言和绑定带来重大更改。在升级运行时的主要版本时，请考虑创建一个新的功能应用程序，然后将功能迁移到该新应用程序。
- 在空的功能应用程序中（删除现有功能或创建新应用程序），在功能应用程序设置中更改运行时。
- 如果发布的项目依赖于另一个运行时，我们可以在应用程序设置中直接设置FUNCTIONS_EXTENSION_VERSION。
为避免破坏更改而固定了次要版本（可能计划在今年秋天将最后一次作为2.x使用的版本是GA。）

请参见2.0.12050-alpha(beta)中的breaking changes，我们可以将FUNCTIONS_EXTENSION_VERSION固定到2.0.11961-alpha，并按照步骤进行更改并移至测试版。

找到more breaking changes来修复我们的2.x函数运行时是否固定到某些旧版本，这些旧版本已在Azure上删除。

版本处理程序错误

如果我们指定错误的1.x版本（如1.0.14），Azure将改为使用最新的次要版本。与2.x相同。

对于本地开发人员

通常来说，本地开发人员不需要运行时配置，因为我们首先选择了Cli（在后台使用npm或VS这样的工具），至少我们了解主要版本。

一些本地地方可以找到函数运行时版本。

VS，新功能项目v1或v2。
VS / VSCode c＃函数，位于functionappname.csproj中，请参见<AzureFunctionsVersion>v2</AzureFunctionsVersion>。
VSCode，functionapp / .vscode / setting.json，请参见"azureFunctions.projectRuntime": "~2"
功能核心工具（Cli），运行func，我们可能会看到Function Runtime Version:2.0.12050.0
在VS / VSCode / Cli中启动一个功能应用程序，除了4，我们还可以看到Cli输出Starting Host (HostId=xx, InstanceId=xx, Version=2.0.12050.0, ..)

非常有用的信息，谢谢杰里！我设法通过不使用.NET Standard来重新创建Azure函数来解决我的问题。 Azure让您知道更改某些设置可能导致该功能无法正常运行。在门户和项目中都设置了适当的运行时重新创建后，它就可以工作了。