Merge pull request #297659 from ggailey777/fixup

[Functions] Package various proposed fixes in the private repo

Author: JamesJBarnett

articles/azure-functions/durable/durable-functions-dotnet-isolated-overview.md

@@ -86,15 +86,20 @@ public class MyOrchestration : TaskOrchestrator<string, string>
 ```
 
 ## Durable entities
-Durable entities are supported in the .NET isolated worker. See [developer's guide](./durable-functions-dotnet-entities.md).
+
+Durable entities are supported in the .NET isolated worker. For more information, see the [developer's guide](./durable-functions-dotnet-entities.md).
 
 ## Migration guide
 
-This guide assumes you're starting with a .NET Durable Functions 2.x project.
+This process assumes you're starting with a .NET Durable Functions 2.x project running in-process with the Functions host. 
+
+### Migrate your project
+
+The first step is to [migrate your .NET project to the isolated worker process](../migrate-dotnet-to-isolated-model.md). 
 
-### Update your project
+### Update package reference 
 
-The first step is to update your project to [Azure Functions .NET isolated](../migrate-dotnet-to-isolated-model.md). Then, update your Durable Functions NuGet package references.
+After you've migrated your app to use the isolate worker process, you must update your Durable Functions NuGet package to reference the isolated worker-specific package, like in this example:
 
 Old:
 

articles/azure-functions/durable/durable-functions-overview.md

@@ -1108,6 +1108,8 @@ Most HTTP trigger templates require an access key in the request. So your HTTP r
 https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?code=<API_KEY>
 ```
 
+Function apps that run in containers use the domain of the container host. For an example HTTP endpoint hosted in Azure Container Apps, see the example in [this Container Apps hosting article](functions-deploy-container-apps.md#verify-your-functions-on-azure).
+
 The key can be included in a query string variable named `code`, as mentioned earlier. It can also be included in an `x-functions-key` HTTP header. The value of the key can be any function key defined for the function, or any host key.
 
 You can allow anonymous requests, which don't require keys. You can also require that the master key is used. You change the default authorization level by using the `authLevel` property in the binding JSON. 

articles/azure-functions/functions-bindings-http-webhook-trigger.md

@@ -41,7 +41,7 @@ Next, you create a function in the new function app.
 
 ## Create Azure Cosmos DB trigger
 
-1. In your function app, select **Overview**, and then select **+ Create** under **Functions**.
+1. In your function app, select **Overview** and then select **+ Create** under **Functions**. If you don't see a **Create** button, you must instead add your Azure Cosmos DB trigger to your local code project and then redeploy to Azure. For more information, see [Code and test Azure Functions locally](functions-develop-local.md).
 
 1. Under **Select a template**, scroll down and choose the **Azure Cosmos DB trigger** template.
 

articles/azure-functions/functions-create-cosmos-db-triggered-function.md

@@ -88,7 +88,7 @@ Next, create a function in the new function app.
 ::: zone pivot="programming-language-python,programming-language-javascript,programming-language-powershell,programming-language-csharp"  
 ## <a name="create-function"></a>Create an HTTP trigger function
 
-1. In your function app, select **Overview**, and then select **+ Create** under **Functions**. If you don't see the **+ Create** button, you can instead [create your functions locally](#create-your-functions-locally).
+1. In your function app, select **Overview**, and then select **+ Create** under **Functions**. If you don't see the **+ Create** button, you must instead [create your functions locally](./functions-develop-local.md).
 
 1. Under **Select a template**, scroll down and choose the **HTTP trigger** template.
 

articles/azure-functions/functions-create-function-app-portal.md

@@ -8,8 +8,8 @@ ms.author: mahender
 
 #### JSON serialization
 
-By default, the isolated worker model uses `System.Text.Json` for JSON serialization. To customize serializer options or switch to JSON.NET (`Newtonsoft.Json`), see [these instructions](../articles/azure-functions/dotnet-isolated-process-guide.md#customizing-json-serialization).
+By default, the isolated worker model uses *System.Text.Json* for JSON serialization. To customize serializer options or switch to JSON.NET (*Newtonsoft.Json*), see [Customizing JSON serialization](../articles/azure-functions/dotnet-isolated-process-guide.md#customizing-json-serialization).
 
 #### Application Insights log levels and filtering
 
-Logs can be sent to Application Insights from both the Functions host runtime and code in your project. The `host.json` allows you to configure rules for host logging, but to control logs coming from your code, you'll need to configure filtering rules as part of your `Program.cs`. See [Managing log levels in the isolated worker model](../articles/azure-functions/dotnet-isolated-process-guide.md#managing-log-levels) for details on how to filter these logs.
+Logs can be sent to Application Insights from both the Functions host runtime and code in your project. The *host.json* allows you to configure rules for host logging, but to control logs coming from your code, you need to configure filtering rules as part of your *Program.cs*. See [Managing log levels in the isolated worker model](../articles/azure-functions/dotnet-isolated-process-guide.md#managing-log-levels) for details on how to filter these logs.

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

@@ -6,10 +6,10 @@ ms.date: 03/28/2024
 ms.author: mahender
 ---
 
-The `Program.cs` file will replace any file that has the `FunctionsStartup` attribute, which is typically a `Startup.cs` file. In places where your `FunctionsStartup` code would reference `IFunctionsHostBuilder.Services`, you can instead add statements within the `.ConfigureServices()` method of the `HostBuilder` in your `Program.cs`. To learn more about working with `Program.cs`, see [Start-up and configuration](../articles/azure-functions/dotnet-isolated-process-guide.md#start-up-and-configuration) in the isolated worker model guide.
+The *Program.cs* file replaces any file that has the `FunctionsStartup` attribute, which is typically a *Startup.cs* file. In places where your `FunctionsStartup` code would reference `IFunctionsHostBuilder.Services`, you can instead add statements within the `.ConfigureServices()` method of the `HostBuilder` in your *Program.cs*. To learn more about working with *Program.cs*, see [Start-up and configuration](../articles/azure-functions/dotnet-isolated-process-guide.md#start-up-and-configuration) in the isolated worker model guide.
 
-The default `Program.cs` examples above include setup of [Application Insights integration for the isolated worker model](../articles/azure-functions/dotnet-isolated-process-guide.md#application-insights). In your `Program.cs`, you must also configure any log filtering that should apply to logs coming from code in your project. In the isolated worker model, the `host.json` file only controls events emitted by the Functions host runtime. If you don't configure filtering rules in `Program.cs`, you may see differences in the log levels present for various categories in your telemetry.
+The default *Program.cs* examples previously described include setup of [Application Insights](../articles/azure-functions/dotnet-isolated-process-guide.md#application-insights). In your *Program.cs*, you must also configure any log filtering that should apply to logs coming from code in your project. In the isolated worker model, the *host.json* file only controls events emitted by the Functions host runtime. If you don't configure filtering rules in *Program.cs*, you might see differences in the log levels present for various categories in your telemetry.
 
-Although you can register custom configuration sources as part of the `HostBuilder`, note that these similarly apply only to code in your project. Trigger and binding configuration is also needed by the platform, and this should be provided through the [application settings](../articles/app-service/configure-common.md#configure-app-settings), [Key Vault references](../articles/app-service/app-service-key-vault-references.md?toc=%2Fazure%2Fazure-functions%2Ftoc.json), or [App Configuration references](../articles/app-service/app-service-configuration-references.md?toc=%2Fazure%2Fazure-functions%2Ftoc.json) features.
+Although you can register custom configuration sources as part of the `HostBuilder`, these similarly apply only to code in your project. The platform also needs trigger and binding configuration, and this should be provided through the [application settings](../articles/app-service/configure-common.md#configure-app-settings), [Key Vault references](../articles/app-service/app-service-key-vault-references.md?toc=%2Fazure%2Fazure-functions%2Ftoc.json), or [App Configuration references](../articles/app-service/app-service-configuration-references.md?toc=%2Fazure%2Fazure-functions%2Ftoc.json) features.
 
-Once you have moved everything from any existing `FunctionsStartup` to the `Program.cs` file, you can delete the `FunctionsStartup` attribute and the class it was applied to.
+After you move everything from any existing `FunctionsStartup` to the *Program.cs* file, you can delete the `FunctionsStartup` attribute and the class it was applied to.