Merge pull request #288644 from MicrosoftDocs/main

10/17/2024 AM Publish

Author: Taojunshen

.openpublishing.redirection.json

@@ -3100,6 +3100,16 @@
       "redirect_url": "https://docs.sendgrid.com/for-developers/partners/microsoft-azure-2021#create-a-twilio-sendgrid-account",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/synapse-analytics/whats-new.md",
+      "redirect_url": "/fabric/get-started/whats-new",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/synapse-analytics/whats-new-archive.md",
+      "redirect_url": "/fabric/get-started/whats-new",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/terraform/terrafom-quickstart.md",
       "redirect_url": "/azure/terraform/terraform-create-configuration",

articles/app-service/app-service-key-vault-references.md

@@ -102,13 +102,13 @@ A key vault reference is of the form `@Microsoft.KeyVault({referenceString})`, w
 > [!div class="mx-tdBreakAll"]
 > | Reference string                                                            | Description                                                                                                                                                                                 |
 > |-----------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-> | SecretUri=_secretUri_                                                       | The **SecretUri** should be the full data-plane URI of a secret in the vault, optionally including a version, e.g., `https://myvault.vault.azure.net/secrets/mysecret/` or `https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931`  |
+> | SecretUri=_secretUri_                                                       | The **SecretUri** should be the full data-plane URI of a secret in the vault, for example `https://myvault.vault.azure.net/secrets/mysecret`. Optionally, include a version, such as `https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931`.  |
 > | VaultName=_vaultName_;SecretName=_secretName_;SecretVersion=_secretVersion_ | The **VaultName** is required and is the vault name. The **SecretName** is required and is the secret name. The **SecretVersion** is optional but if present indicates the version of the secret to use. |
 
-For example, a complete reference would look like the following string:
+For example, a complete reference without a specific version would look like the following string:
 
 ```
-@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)
+@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret)
 ```
 
 Alternatively:

articles/app-service/configure-common.md

@@ -443,7 +443,7 @@ Here, you can configure some common settings for the app. Some settings require
     > [!NOTE]
     > Most modern browsers support HTTP/2 protocol over TLS only, while non-encrypted traffic continues to use HTTP/1.1. To ensure that client browsers connect to your app with HTTP/2, secure your custom DNS name. For more information, see [Secure a custom DNS name with a TLS/SSL binding in Azure App Service](configure-ssl-bindings.md).
     - **Web sockets**: For [ASP.NET SignalR] or [socket.io](https://socket.io/), for example.
-    - **Always On**: Keeps the app loaded even when there's no traffic. When **Always On** isn't turned on (default), the app is unloaded after 20 minutes without any incoming requests. The unloaded app can cause high latency for new requests because of its warm-up time. When **Always On** is turned on, the front-end load balancer sends a GET request to the application root every five minutes. The continuous ping prevents the app from being unloaded.
+    - **Always On**: Keeps the app loaded even when there's no traffic. When **Always On** isn't turned on (default), the app is unloaded after 20 minutes without any incoming requests. The unloaded app can cause high latency for new requests because of its warm-up time. When **Always On** is turned on, the front-end load balancer sends a GET request to the application root every five minutes. It's important to ensure this request receives a 200 OK response to ensure any re-imaging operations are performed correctly. The continuous ping prevents the app from being unloaded.
 
         Always On is required for continuous WebJobs or for WebJobs that are triggered using a CRON expression.
     - **Session affinity**: In a multi-instance deployment, ensure that the client is routed to the same instance for the life of the session. You can set this option to **Off** for stateless applications.

articles/app-service/deploy-github-actions.md

@@ -196,7 +196,7 @@ To use [user-level credentials](#1-generate-deployment-credentials), paste the e
 When you configure the GitHub workflow file later, you use the secret for the input `creds` of the [Azure/login](https://github.com/marketplace/actions/azure-login). For example:
 
 ```yaml
-- uses: azure/login@v1
+- uses: azure/login@v2
   with:
     creds: ${{ secrets.AZURE_CREDENTIALS }}
 ```
@@ -301,4 +301,4 @@ Check out references on Azure GitHub Actions and workflows:
 - [Azure/k8s-deploy action](https://github.com/Azure/k8s-deploy)
 - [Actions workflows to deploy to Azure](https://github.com/Azure/actions-workflow-samples)
 - [Starter Workflows](https://github.com/actions/starter-workflows)
-- [Events that trigger workflows](https://docs.github.com/en/actions/reference/events-that-trigger-workflows)
+- [Events that trigger workflows](https://docs.github.com/en/actions/reference/events-that-trigger-workflows)

articles/app-service/deploy-staging-slots.md

@@ -124,7 +124,7 @@ When you swap two slots (usually from a staging slot *as the source* into the pr
 
 1. Now that the source slot has the pre-swap app previously in the target slot, perform the same operation by applying all settings and restarting the instances.
 
-At any point of the swap operation, all work of initializing the swapped apps happens on the source slot. The target slot remains online while the source slot is being prepared and warmed up, regardless of where the swap succeeds or fails. To swap a staging slot with the production slot, make sure that the production slot is always the target slot. This way, the swap operation doesn't affect your production app.
+At any point of the swap operation, all work of initializing the swapped apps happens on the source slot. The target slot remains online while the source slot is being prepared and warmed up, regardless of whether the swap succeeds or fails. To swap a staging slot with the production slot, make sure that the production slot is always the target slot. This way, the swap operation doesn't affect your production app.
 
 > [!NOTE]
 > The instances in your former production instances (those that will be swapped into staging after this swap operation) will be recycled quickly in the last step of the swap process. In case you have any long running operations in your application, they will be abandoned, when the workers recycle. This also applies to function apps. Therefore your application code should be written in a fault tolerant way. 

articles/automation/update-management/operating-system-requirements.md

@@ -4,16 +4,13 @@ description: This article describes the supported Windows and Linux operating sy
 services: automation
 ms.subservice: update-management
 ms.custom: linux-related-content
-ms.date: 09/15/2024
+ms.date: 10/17/2024
 ms.topic: overview
 ms.service: azure-automation
 ---
 
 # Operating systems supported by Update Management
 
-> [!CAUTION]
-> This article references CentOS, a Linux distribution that is End Of Life (EOL) status. Please consider your use and planning accordingly. For more information, see the [CentOS End Of Life guidance](/azure/virtual-machines/workloads/centos/centos-end-of-life).
-
 This article details the Windows and Linux operating systems supported and system requirements for machines or servers managed by Update Management.
 
 [!INCLUDE [./automation-update-management-retirement-announcement.md](../includes/automation-update-management-retirement-announcement.md)]

articles/azure-functions/functions-develop-vs.md

@@ -219,6 +219,13 @@ For a full list of the bindings supported by Functions, see [Supported bindings]
 
 Azure Functions Core Tools lets you run Azure Functions project on your local development computer. When you press F5 to debug a Functions project, the local Functions host (func.exe) starts to listen on a local port (usually 7071). Any callable function endpoints are written to the output, and you can use these endpoints for testing your functions. For more information, see [Work with Azure Functions Core Tools](functions-run-local.md). You're prompted to install these tools the first time you start a function from Visual Studio.
 
+::: zone pivot="in-proc" 
+
+> [!IMPORTANT]
+> Starting with version 4.0.6517 of the Core Tools, in-process model projects must reference [version 4.5.0 or later of `Microsoft.NET.Sdk.Functions`](https://www.nuget.org/packages/Microsoft.NET.Sdk.Functions/4.5.0). If an earlier version is used, the `func start` command will error.
+
+::: zone-end  
+
 To start your function in Visual Studio in debug mode:
 
 1. Press F5. If prompted, accept the request from Visual Studio to download and install Azure Functions Core (CLI) tools. You might also need to enable a firewall exception so that the tools can handle HTTP requests.

articles/azure-functions/functions-dotnet-class-library.md

@@ -226,10 +226,13 @@ The following example shows the relevant parts of the `.csproj` files that have
   <AzureFunctionsVersion>v4</AzureFunctionsVersion>
 </PropertyGroup>
 <ItemGroup>
-  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.4.0" />
+  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.5.0" />
 </ItemGroup>
 ```
 
+> [!IMPORTANT]
+> Starting with version 4.0.6517 of the Core Tools, in-process model projects must reference [version 4.5.0 or later of `Microsoft.NET.Sdk.Functions`](https://www.nuget.org/packages/Microsoft.NET.Sdk.Functions/4.5.0). If an earlier version is used, the `func start` command will error.
+
 # [v1.x](#tab/v1)
 
 ```xml

articles/azure-functions/functions-run-local.md

@@ -55,15 +55,15 @@ For help with version-related issues, see [Core Tools versions](#v2).
 In the terminal window or from a command prompt, run the following command to create a project in the `MyProjFolder` folder:
 
 ::: zone pivot="programming-language-csharp"
-### [Isolated process](#tab/isolated-process)
+### [Isolated worker model](#tab/isolated-process)
 
 ```console
 func init MyProjFolder --worker-runtime dotnet-isolated 
 ```
 
 By default this command creates a project that runs in-process with the Functions host on the current [Long-Term Support (LTS) version of .NET Core]. You can use the `--target-framework` option to target a specific supported version of .NET, including .NET Framework. For more information, see the [`func init`](functions-core-tools-reference.md#func-init) reference.
 
-### [In-process](#tab/in-process)
+### [In-process model](#tab/in-process)
 
 ```console
 func init MyProjFolder --worker-runtime dotnet 
@@ -199,7 +199,27 @@ mvn clean package
 mvn azure-functions:run
 ```
 ::: zone-end  
-::: zone pivot="programming-language-csharp,programming-language-javascript,programming-language-powershell,programming-language-python"  
+::: zone pivot="programming-language-csharp"  
+
+### [Isolated worker model](#tab/isolated-process)
+
+```
+func start
+```
+
+### [In-process model](#tab/in-process)
+
+```
+func start
+```
+
+> [!IMPORTANT]
+> Starting with version 4.0.6517 of the Core Tools, in-process model projects must reference [version 4.5.0 or later of `Microsoft.NET.Sdk.Functions`](https://www.nuget.org/packages/Microsoft.NET.Sdk.Functions/4.5.0). If an earlier version is used, the `func start` command will error.
+
+---
+
+::: zone-end  
+::: zone pivot="programming-language-javascript,programming-language-powershell,programming-language-python"  
 ```
 func start
 ```
@@ -513,6 +533,11 @@ If you must use a binding extension or an extension version not in a supported b
 
 Major versions of Azure Functions Core Tools are linked to specific major versions of the Azure Functions runtime. For example, version 4.x of Core Tools supports version 4.x of the Functions runtime. This version is the recommended major version of both the Functions runtime and Core Tools. You can determine the latest release version of Core Tools in the [Azure Functions Core Tools repository](https://github.com/Azure/azure-functions-core-tools/releases/latest).
 
+::: zone pivot="programming-language-csharp"
+<a name="in-process-minimum-version"></a> 
+Starting with version 4.0.6517 of the Core Tools, in-process model projects must reference [version 4.5.0 or later of `Microsoft.NET.Sdk.Functions`](https://www.nuget.org/packages/Microsoft.NET.Sdk.Functions/4.5.0). If an earlier version is used, the `func start` command will error.
+::: zone-end
+
 Run the following command to determine the version of your current Core Tools installation:
 
 ```command