Merge branch 'master' of https://github.com/Microsoft/azure-docs-pr

Author: [email protected]

articles/application-insights/app-insights-analytics-using.md

@@ -133,7 +133,7 @@ On a timechart, if there is a sudden spike or step in your data, you may see a h
 ![Analytics diagnostics](./media/app-insights-analytics-using/analytics-diagnostics.png)
 
 ## Pin to dashboard
-You can pin a diagram or table to one of your [shared dashboards](app-insights-dashboards.md) - just click the pin. (You might need to [upgrade your app's pricing package](app-insights-pricing.md) to turn on this feature.) 
+You can pin a diagram or table to one of your [shared dashboards](app-insights-dashboards.md) - just click the pin. 
 
 ![Click the pin](./media/app-insights-analytics-using/pin-01.png)
 

articles/application-insights/app-insights-asp-net-exceptions.md

@@ -29,8 +29,8 @@ Exceptions in your live web app are reported by [Application Insights](app-insig
 * In some application frameworks or with some settings, you need to take some extra steps to catch more exceptions:
   * [Web forms](#web-forms)
   * [MVC](#mvc)
-  * [Web API 1.*](#web-api-1)
-  * [Web API 2.*](#web-api-2)
+  * [Web API 1.*](#web-api-1x)
+  * [Web API 2.*](#web-api-2x)
   * [WCF](#wcf)
 
 ## Diagnosing exceptions using Visual Studio

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

@@ -27,8 +27,8 @@ In addition to script files, Azure Functions supports publishing a class library
 
 This article has the following prerequisites:
 
-- [Visual Studio 2017 15.3 Preview](https://www.visualstudio.com/vs/preview/). Install the workloads **ASP.NET and web development** and **Azure development**.
-- [Azure Function Tools for Visual Studio 2017](https://marketplace.visualstudio.com/items?itemName=AndrewBHall-MSFT.AzureFunctionToolsforVisualStudio2017)
+- [Visual Studio 2017 version 15.3](https://www.visualstudio.com/vs/), or a later version.
+- Install the **Azure development** workload.
 
 ## Functions class library project
 
@@ -73,7 +73,7 @@ The following table lists the triggers and bindings that are available in an Azu
 
 Azure Functions supports trigger, input, and output bindings for Azure Blob storage. For more information on binding expressions and metadata, see [Azure Functions Blob storage bindings](functions-bindings-storage-blob.md).
 
-A blob trigger is defined with the `[BlobTrigger]` attribute. You can use the attribute `[StorageAccount]` to define the storage account that is used by an entire function or class.
+A blob trigger is defined with the `[BlobTrigger]` attribute. You can use the attribute `[StorageAccount]` to define the app setting name that contains the connection string to the storage account that is used by an entire function or class.
 
 ```csharp
 [StorageAccount("AzureWebJobsStorage")]
@@ -242,7 +242,7 @@ Azure Functions supports an output binding for Notification Hubs. To learn more,
 
 Azure Functions supports trigger and output bindings for Azure queues. For more information, see [Azure Functions Queue Storage bindings](functions-bindings-storage-queue.md).
 
-The following example shows how to use the function return type with a queue output binding, using the `[Queue]` attribute. To define a queue trigger, use the `[QueueTrigger]` attribute.
+The following example shows how to use the function return type with a queue output binding, using the `[Queue]` attribute. 
 
 ```csharp
 [StorageAccount("AzureWebJobsStorage")]
@@ -256,7 +256,15 @@ public static class QueueFunctions
         log.Info($"C# function processed: {input.Text}");
         return input.Text;
     }
+}
+
+```
 
+To define a queue trigger, use the `[QueueTrigger]` attribute.
+```csharp
+[StorageAccount("AzureWebJobsStorage")]
+public static class QueueFunctions
+{
     // Queue trigger
     [FunctionName("QueueTrigger")]
     [StorageAccount("AzureWebJobsStorage")]
@@ -268,6 +276,7 @@ public static class QueueFunctions
 
 ```
 
+
 <a name="sendgrid"></a>
 
 ### SendGrid output

articles/azure-functions/functions-overview.md

@@ -15,7 +15,7 @@ ms.devlang: multiple
 ms.topic: overview
 ms.tgt_pltfrm: multiple
 ms.workload: na
-ms.date: 02/27/2017
+ms.date: 10/03/2017
 ms.author: glenga
 
 ms.custom: H1Hack27Feb2017, mvc
@@ -46,6 +46,7 @@ Functions provides templates to get you started with key scenarios, including th
 * **TimerTrigger** - Execute cleanup or other batch tasks on a predefined schedule. For an example, see [Create a function triggered by a timer](functions-create-scheduled-function.md).
 * **GitHub webhook** - Respond to events that occur in your GitHub repositories. For an example, see [Create a function triggered by a GitHub webhook](functions-create-github-webhook-triggered-function.md).
 * **Generic webhook** - Process webhook HTTP requests from any service that supports webhooks. For an example, see [Create a function triggered by a generic webhook](functions-create-generic-webhook-triggered-function.md).
+* **CosmosDBTrigger** - Process Azure Cosmos DB documents when they are added or updated in collections in a NoSQL database. For an example, see [Create a function triggered by Azure Cosmos DB](functions-create-cosmos-db-triggered-function.md).
 * **BlobTrigger** - Process Azure Storage blobs when they are added to containers. You might use this function for image resizing. For more information, see [Blob storage bindings](functions-bindings-storage-blob.md).
 * **QueueTrigger** - Respond to messages as they arrive in an Azure Storage queue. For an example, see [Create a function that connects to other Azure services](functions-create-an-azure-connected-function.md).
 * **EventHubTrigger** -  Respond to events delivered to an Azure Event Hub. Particularly useful in application instrumentation, user experience or workflow processing, and Internet of Things (IoT) scenarios. For more information, see [Event Hubs bindings](functions-bindings-event-hubs.md).

articles/azure-functions/functions-reference-csharp.md

@@ -79,7 +79,7 @@ public static string Run(string input, TraceWriter log)
 
 To write multiple values to an output binding, use the [`ICollector`](https://github.com/Azure/azure-webjobs-sdk/blob/master/src/Microsoft.Azure.WebJobs/ICollector.cs) or [`IAsyncCollector`](https://github.com/Azure/azure-webjobs-sdk/blob/master/src/Microsoft.Azure.WebJobs/IAsyncCollector.cs) types. These types are write-only collections that are written to the output binding when the method completes.
 
-This example writes multiple queue messages using `ICollector`:
+This example writes multiple queue messages into the same queue using `ICollector`:
 
 ```csharp
 public static void Run(ICollector<string> myQueueItem, TraceWriter log)
@@ -402,8 +402,7 @@ public static async Task Run(string input, Binder binder)
 [BlobAttribute](https://github.com/Azure/azure-webjobs-sdk/blob/master/src/Microsoft.Azure.WebJobs/BlobAttribute.cs)
 defines the [Storage blob](functions-bindings-storage-blob.md) input or output binding, and
 [TextWriter](https://msdn.microsoft.com/library/system.io.textwriter.aspx) is a supported output binding type.
-As is, the code gets the default app setting for the Storage account connection string (which is `AzureWebJobsStorage`). You can specify a
-custom app setting to use by adding the
+In the previous code sample, the code gets the app setting for the function app's main Storage account connection string (which is `AzureWebJobsStorage`). You can specify a custom app setting to use for the Storage account by adding the
 [StorageAccountAttribute](https://github.com/Azure/azure-webjobs-sdk/blob/master/src/Microsoft.Azure.WebJobs/StorageAccountAttribute.cs)
 and passing the attribute array into `BindAsync<T>()`. For example,
 

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

@@ -153,7 +153,7 @@ To set a value for connection strings, you can do one of the following options:
     func azure functionapp fetch-app-settings <FunctionAppName>
     ```
     ```
-    func azure functionapp storage fetch-connection-string <StorageAccountName>
+    func azure storage fetch-connection-string <StorageAccountName>
     ```
     Both commands require you to first sign-in to Azure.
 

articles/azure-functions/functions-scale.md

@@ -34,9 +34,9 @@ When you create a function app, you must configure a hosting plan for functions
 * How host instances are scaled out.
 * The resources that are available to each host.
 
-Currently, you must choose the plan type during the creation of the function app. You can't change it afterward. 
+Currently, you must choose the type of hosting plan during the creation of the function app. You can't change it afterward. 
 
-You can scale between tiers on the App Service plan. On the Consumption plan, Azure Functions automatically handles all resource allocation.
+On an App Service plan you can scale between tiers to allocate different amount of resources. On the Consumption plan, Azure Functions automatically handles all resource allocation.
 
 ## Consumption plan
 
@@ -45,26 +45,28 @@ When you're using a Consumption plan, instances of the Azure Functions host are
 > [!NOTE]
 > The default timeout for functions on a Consumption plan is 5 minutes. The value can be increased to 10 minutes for the Function App by changing the property `functionTimeout` in [host.json](https://github.com/Azure/azure-webjobs-sdk-script/wiki/host.json).
 
-Billing is based on execution time and memory used, and it's aggregated across all functions within a function app. For more information, see the [Azure Functions pricing page].
+Billing is based on number of executions, execution time, and memory used. Billing is aggregated across all functions within a function app. For more information, see the [Azure Functions pricing page].
 
-The Consumption plan is the default and offers the following benefits:
+The Consumption plan is the default hosting plan and offers the following benefits:
 - Pay only when your functions are running.
 - Scale out automatically, even during periods of high load.
 
 ## App Service plan
 
-In the App Service plan, your function apps run on dedicated VMs on Basic, Standard, Premium, and Isolated SKUs, similar to Web Apps. Dedicated VMs are allocated to your App Service apps, which means the functions host is always running.
+In the App Service plan, your function apps run on dedicated VMs on Basic, Standard, Premium, and Isolated SKUs, similar to Web Apps, API Apps, and Mobile Apps. Dedicated VMs are allocated to your App Service apps, which means the functions host is always running.
 
 Consider an App Service plan in the following cases:
 - You have existing, underutilized VMs that are already running other App Service instances.
 - You expect your function apps to run continuously, or nearly continuously. In this case, an App Service Plan can be more cost-effective.
 - You need more CPU or memory options than what is provided on the Consumption plan.
-- You need to run longer than the maximum execution time allowed on the Consumption plan.
+- You need to run longer than the maximum execution time allowed on the Consumption plan (of 10 minutes).
 - You require features that are only available on an App Service plan, such as support for App Service Environment, VNET/VPN connectivity, and larger VM sizes. 
 
-A VM decouples cost from both runtime and memory size. As a result, you won't pay more than the cost of the VM instance that you allocate. For details about how the App Service plan works, see the [Azure App Service plans in-depth overview](../app-service/azure-web-sites-web-hosting-plans-in-depth-overview.md). 
+A VM decouples cost from number of executions, execution time, and memory used. As a result, you won't pay more than the cost of the VM instance that you allocate. For details about how the App Service plan works, see the [Azure App Service plans in-depth overview](../app-service/azure-web-sites-web-hosting-plans-in-depth-overview.md). 
 
-With an App Service plan, you can manually scale out by adding more VM instances, or you can enable autoscale. For more information, see [Scale instance count manually or automatically](../monitoring-and-diagnostics/insights-how-to-scale.md?toc=%2fazure%2fapp-service-web%2ftoc.json). You can also scale up by choosing a different App Service plan. For more information, see [Scale up an app in Azure](../app-service/web-sites-scale.md). If you are planning to run JavaScript functions on an App Service plan, you should choose a plan that has fewer cores. For more information, see the [JavaScript reference for Functions](functions-reference-node.md#choose-single-core-app-service-plans).  
+With an App Service plan, you can manually scale out by adding more VM instances, or you can enable autoscale. For more information, see [Scale instance count manually or automatically](../monitoring-and-diagnostics/insights-how-to-scale.md?toc=%2fazure%2fapp-service-web%2ftoc.json). You can also scale up by choosing a different App Service plan. For more information, see [Scale up an app in Azure](../app-service/web-sites-scale.md). 
+
+If you are planning to run JavaScript functions on an App Service plan, you should choose a plan that has fewer cores. For more information, see the [JavaScript reference for Functions](functions-reference-node.md#choose-single-core-app-service-plans).  
 
 <!-- Note: the portal links to this section via fwlink https://go.microsoft.com/fwlink/?linkid=830855 --> 
 <a name="always-on"></a>
@@ -76,33 +78,33 @@ Always On is available only on an App Service plan. On a Consumption plan, the p
 
 ## Storage account requirements
 
-On either a Consumption plan or an App Service plan, a function app requires an Azure Storage account that supports Azure Blob, Queue, and Table storage. Internally, Azure Functions uses Azure Storage for operations such as managing triggers and logging function executions. Some storage accounts do not support queues and tables, such as blob-only storage accounts (including premium storage) and general-purpose storage accounts with zone-redundant storage replication. These accounts are filtered from the **Storage Account** blade when you're creating a function app.
+On either a Consumption plan or an App Service plan, a function app requires a general Azure Storage account that supports Azure Blob, Queue, Files, and Table storage. Internally, Azure Functions uses Azure Storage for operations such as managing triggers and logging function executions. Some storage accounts do not support queues and tables, such as blob-only storage accounts (including premium storage) and general-purpose storage accounts with zone-redundant storage replication. These accounts are filtered from the **Storage Account** blade when you're creating a function app.
 
 To learn more about storage account types, see [Introducing the Azure Storage services](../storage/common/storage-introduction.md#introducing-the-azure-storage-services).
 
 ## How the Consumption plan works
 
-The Consumption plan automatically scales CPU and memory resources by adding additional instances of the Functions host, based on the number of events that its functions are triggered on. Each instance of the Functions host is limited to 1.5 GB of memory.
+In the Consumption plan, the scale controller automatically scales CPU and memory resources by adding additional instances of the Functions host, based on the number of events that its functions are triggered on. Each instance of the Functions host is limited to 1.5 GB of memory.
 
-When you use the Consumption hosting plan, function code files are stored on Azure Files shares on the main storage account. When you delete the main storage account, this content is deleted and cannot be recovered.
+When you use the Consumption hosting plan, function code files are stored on Azure Files shares on the function's main storage account. When you delete the main storage account of the function app, the function code files are deleted and cannot be recovered.
 
 > [!NOTE]
 > When you're using a blob trigger on a Consumption plan, there can be up to a 10-minute delay in processing new blobs if a function app has gone idle. After the function app is running, blobs are processed immediately. To avoid this initial delay, consider one of the following options:
-> - Use an App Service plan with Always On enabled.
+> - Host the function app on an App Service plan, with Always On enabled.
 > - Use another mechanism to trigger the blob processing, such as a queue message that contains the blob name. For an example, see [Queue trigger with blob input binding](functions-bindings-storage-blob.md#input-sample).
 
 ### Runtime scaling
 
 Azure Functions uses a component called the *scale controller* to monitor the rate of events and determine whether to scale out or scale in. The scale controller uses heuristics for each trigger type. For example, when you're using an Azure Queue storage trigger, it scales based on the queue length and the age of the oldest queue message.
 
-The unit of scale is the function app. When the function app is scaled out, more resources are allocated to run multiple instances of the Azure Functions host. Conversely, as compute demand is reduced, the scale controller removes function host instances. The number of instances is eventually scaled down to zero when no functions are running within a function app.
+The unit of scale is the function app. When the function app is scaled out, additional resources are allocated to run multiple instances of the Azure Functions host. Conversely, as compute demand is reduced, the scale controller removes function host instances. The number of instances is eventually scaled down to zero when no functions are running within a function app.
 
 ![Scale controller monitoring events and creating instances](./media/functions-scale/central-listener.png)
 
 ### Billing model
 
 Billing for the Consumption plan is described in detail on the [Azure Functions pricing page]. Usage is aggregated at the function app level and counts only the time that function code is executed. The following are units for billing: 
 * **Resource consumption in gigabyte-seconds (GB-s)**. Computed as a combination of memory size and execution time for all functions within a function app. 
-* **Executions**. Counted each time a function is executed in response to an event, triggered by a binding.
+* **Executions**. Counted each time a function is executed in response to an event trigger.
 
 [Azure Functions pricing page]: https://azure.microsoft.com/pricing/details/functions