Merge pull request #264507 from ggailey777/brett

[Functions] Brett outstanding commits

Author: v-regandowner

articles/azure-functions/TOC.yml

@@ -1003,7 +1003,9 @@
           - name: AZFD0009
             href: errors-diagnostics/diagnostic-events/azfd0009.md     
           - name: AZFD0010
-            href: errors-diagnostics/diagnostic-events/azfd0010.md            
+            href: errors-diagnostics/diagnostic-events/azfd0010.md
+          - name: AZFD0011
+            href: errors-diagnostics/diagnostic-events/azfd0011.md
     - name: host.json 2.x reference
       href: functions-host-json.md
     - name: host.json 1.x reference

articles/azure-functions/errors-diagnostics/diagnostic-events/azfd0011.md

@@ -0,0 +1,35 @@
+---
+title: "AZFD0011: The FUNCTIONS_WORKER_RUNTIME setting is required"
+titleSuffix: "Azure Functions"
+description: "Learn how to troubleshoot the event 'AZFD0011: The FUNCTIONS_WORKER_RUNTIME setting is required' in Azure Functions."
+ms.topic: reference
+ms.date: 01/24/2024
+
+---
+
+# AZFD0011: The FUNCTIONS_WORKER_RUNTIME setting is required
+
+This event occurs when a function app doesn't have the `FUNCTIONS_WORKER_RUNTIME` application setting, which is required.
+
+| | Value |
+|-|-|
+| **Event ID** |AZFD0011|
+| **Severity** |Warning|
+
+## Event description
+
+The `FUNCTIONS_WORKER_RUNTIME` application setting indicates the language or language stack on which the function app runs, such as `python`. For more information on valid values, see the [`FUNCTIONS_WORKER_RUNTIME`](../../functions-app-settings.md#functions_worker_runtime) reference.
+
+While not currently required, you should always specify `FUNCTIONS_WORKER_RUNTIME` for your function apps. When you don't have this setting and the Functions host can't determine the correct language or language stack, you might see exceptions or unexpected behaviors. 
+
+Because `FUNCTIONS_WORKER_RUNTIME` is likely to become a required setting, you should explicitly set it in all of your existing function apps and deployment scripts to prevent any downtime in the future.
+
+## How to resolve the event
+
+In a production application, add `FUNCTIONS_WORKER_RUNTIME` to the [application settings](../../functions-how-to-use-azure-function-app-settings.md#settings).
+
+When running locally in Azure Functions Core Tools, also add `FUNCTIONS_WORKER_RUNTIME` to the [local.settings.json file](../../functions-develop-local.md#local-settings-file).
+
+## When to suppress the event
+
+This event shouldn't be suppressed.

articles/azure-functions/functions-dotnet-dependency-injection.md

@@ -71,13 +71,15 @@ This example uses the [Microsoft.Extensions.Http](https://www.nuget.org/packages
 
 A series of registration steps run before and after the runtime processes the startup class. Therefore, keep in mind the following items:
 
-- *The startup class is meant for only setup and registration.* Avoid using services registered at startup during the startup process. For instance, don't try to log a message in a logger that is being registered during startup. This point of the registration process is too early for your services to be available for use. After the `Configure` method is run, the Functions runtime continues to register additional dependencies, which can affect how your services operate.
+- *The startup class is meant for only setup and registration.* Avoid using services registered at startup during the startup process. For instance, don't try to log a message in a logger that is being registered during startup. This point of the registration process is too early for your services to be available for use. After the `Configure` method is run, the Functions runtime continues to register other dependencies, which can affect how your services operate.
 
-- *The dependency injection container only holds explicitly registered types*. The only services available as injectable types are what are setup in the `Configure` method. As a result, Functions-specific types like `BindingContext` and `ExecutionContext` aren't available during setup or as injectable types.
+- *The dependency injection container only holds explicitly registered types*. The only services available as injectable types are what are set up in the `Configure` method. As a result, Functions-specific types like `BindingContext` and `ExecutionContext` aren't available during setup or as injectable types.
+
+- *Configuring ASP.NET authentication isn't supported*. The Functions host configures ASP.NET authentication services to properly expose APIs for core lifecycle operations. Other configurations in a custom `Startup` class can override this configuration, causing unintended consequences. For example, calling `builder.Services.AddAuthentication()` can break authentication between the portal and the host, leading to messages such as [Azure Functions runtime is unreachable](./functions-recover-storage-account.md#aspnet-authentication-overrides).
 
 ## Use injected dependencies
 
-Constructor injection is used to make your dependencies available in a function. The use of constructor injection requires that you do not use static classes for injected services or for your function classes.
+Constructor injection is used to make your dependencies available in a function. The use of constructor injection requires that you don't use static classes for injected services or for your function classes.
 
 The following sample demonstrates how the `IMyService` and `HttpClient` dependencies are injected into an HTTP-triggered function.
 
@@ -140,7 +142,7 @@ Application Insights is added by Azure Functions automatically.
 
 ### ILogger\<T\> and ILoggerFactory
 
-The host injects `ILogger<T>` and `ILoggerFactory` services into constructors.  However, by default these new logging filters are filtered out of the function logs.  You need to modify the `host.json` file to opt-in to additional filters and categories.
+The host injects `ILogger<T>` and `ILoggerFactory` services into constructors.  However, by default these new logging filters are filtered out of the function logs.  You need to modify the `host.json` file to opt in to extra filters and categories.
 
 The following example demonstrates how to add an `ILogger<HttpTrigger>` with logs that are exposed to the host.
 
@@ -206,7 +208,7 @@ Overriding services provided by the host is currently not supported.  If there a
 
 Values defined in [app settings](./functions-how-to-use-azure-function-app-settings.md#settings) are available in an `IConfiguration` instance, which allows you to read app settings values in the startup class.
 
-You can extract values from the `IConfiguration` instance into a custom type. Copying the app settings values to a custom type makes it easy test your services by making these values injectable. Settings read into the configuration instance must be simple key/value pairs. Please note that, the functions running on Elastic Premium SKU has this constraint "App setting names can only contain letters, numbers (0-9), periods ("."), colons (":") and underscores ("_")"
+You can extract values from the `IConfiguration` instance into a custom type. Copying the app settings values to a custom type makes it easy test your services by making these values injectable. Settings read into the configuration instance must be simple key/value pairs. For functions running in an Elastic Premium plan, application setting names can only contain letters, numbers (`0-9`), periods (`.`), colons (`:`) and underscores (`_`). For more information, see [App setting considerations](functions-app-settings.md#app-setting-considerations).
 
 Consider the following class that includes a property named consistent with an app setting:
 
@@ -256,11 +258,11 @@ public class HttpTrigger
 }
 ```
 
-Refer to [Options pattern in ASP.NET Core](/aspnet/core/fundamentals/configuration/options) for more details regarding working with options.
+For more information, see [Options pattern in ASP.NET Core](/aspnet/core/fundamentals/configuration/options).
 
 ## Using ASP.NET Core user secrets
 
-When developing locally, ASP.NET Core provides a [Secret Manager tool](/aspnet/core/security/app-secrets#secret-manager) that allows you to store secret information outside the project root. It makes it less likely that secrets are accidentally committed to source control. Azure Functions Core Tools (version 3.0.3233 or later) automatically reads secrets created by the ASP.NET Core Secret Manager.
+When you develop your app locally, ASP.NET Core provides a [Secret Manager tool](/aspnet/core/security/app-secrets#secret-manager) that allows you to store secret information outside the project root. It makes it less likely that secrets are accidentally committed to source control. Azure Functions Core Tools (version 3.0.3233 or later) automatically reads secrets created by the ASP.NET Core Secret Manager.
 
 To configure a .NET Azure Functions project to use user secrets, run the following command in the project root.
 
@@ -278,9 +280,9 @@ To access user secrets values in your function app code, use `IConfiguration` or
 
 ## Customizing configuration sources
 
-To specify additional configuration sources, override the `ConfigureAppConfiguration` method in your function app's `StartUp` class.
+To specify other configuration sources, override the `ConfigureAppConfiguration` method in your function app's `StartUp` class.
 
-The following sample adds configuration values from a base and an optional environment-specific app settings files.
+The following sample adds configuration values from both base and optional environment-specific app settings files.
 
 ```csharp
 using System.IO;
@@ -314,7 +316,7 @@ Add configuration providers to the `ConfigurationBuilder` property of `IFunction
 
 A `FunctionsHostBuilderContext` is obtained from `IFunctionsConfigurationBuilder.GetContext()`. Use this context to retrieve the current environment name and resolve the location of configuration files in your function app folder.
 
-By default, configuration files such as *appsettings.json* are not automatically copied to the function app's output folder. Update your *.csproj* file to match the following sample to ensure the files are copied.
+By default, configuration files such as `appsettings.json` aren't automatically copied to the function app's output folder. Update your `.csproj` file to match the following sample to ensure the files are copied.
 
 ```xml
 <None Update="appsettings.json">

articles/azure-functions/functions-recover-storage-account.md

@@ -96,15 +96,15 @@ For function apps that run on Linux in a container, the `Azure Functions runtime
 
 1. Check for any logged errors that indicate that the container is unable to start successfully.
 
-### Container image unavailable
+## Container image unavailable
 
 Errors can occur when the container image being referenced is unavailable or fails to start correctly. Check for any logged errors that indicate that the container is unable to start successfully.
 
 You need to correct any errors that prevent the container from starting for the function app run correctly.
 
-When the container image can't be found, you'll see a `manifest unknown` error in the Docker logs. In this case, you can use the Azure CLI commands documented at [How to target Azure Functions runtime versions](set-runtime-version.md?tabs=azurecli#manual-version-updates-on-linux) to change the container image being referenced. If you've deployed a [custom container image](./functions-how-to-custom-container.md), you need to fix the image and redeploy the updated version to the referenced registry.
+When the container image can't be found, you see a `manifest unknown` error in the Docker logs. In this case, you can use the Azure CLI commands documented at [How to target Azure Functions runtime versions](set-runtime-version.md?tabs=azurecli#manual-version-updates-on-linux) to change the container image being referenced. If you've deployed a [custom container image](./functions-how-to-custom-container.md), you need to fix the image and redeploy the updated version to the referenced registry.
 
-### App container has conflicting ports
+## App container has conflicting ports
 
 Your function app might be in an unresponsive state due to conflicting port assignment upon startup. This can happen in the following cases:
 
@@ -119,7 +119,12 @@ Starting with version 3.x of the Functions runtime, [host ID collision](storage-
 
 ## Read-only app settings
 
-Changing any _read-only_ [App Service application settings](../app-service/reference-app-settings.md#app-environment) can put your function app into an unreachable state. 
+Changing any _read-only_ [App Service application settings](../app-service/reference-app-settings.md#app-environment) can put your function app into an unreachable state.
+
+## ASP.NET authentication overrides
+_Applies only to C# apps running [in-process with the Functions host](./functions-dotnet-class-library.md)._
+
+Configuring ASP.NET authentication in a Functions startup class can override services that are required for the Azure portal to communicate with the host. This includes, but isn't limited to, any calls to `AddAuthentication()`. If the host's authentication services are overridden and the portal can't communicate with the host, it considers the app unreachable. This issue may result in errors such as: `No authentication handler is registered for the scheme 'ArmToken'.`.
 
 ## Next steps