Skip to content

Commit c92792f

Browse files
committed
Acrolinx
1 parent 73fd4af commit c92792f

File tree

1 file changed

+10
-10
lines changed

1 file changed

+10
-10
lines changed

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

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -28,11 +28,11 @@ Data flows into your C# function via method arguments. Argument names are specif
2828

2929
The *.csx* format allows you to write less "boilerplate" and focus on writing just a C# function. Instead of wrapping everything in a namespace and class, just define a `Run` method. Include any assembly references and namespaces at the beginning of the file as usual.
3030

31-
A function app's *.csx* files are compiled when an instance is initialized. This compilation step means things like cold start may take longer for C# script functions compared to C# class libraries. This compilation step is also why C# script functions are editable in the Azure portal, while C# class libraries are not.
31+
A function app's *.csx* files are compiled when an instance is initialized. This compilation step means things like cold start may take longer for C# script functions compared to C# class libraries. This compilation step is also why C# script functions are editable in the Azure portal, while C# class libraries aren't.
3232

3333
## Folder structure
3434

35-
The folder structure for a C# script project looks like the following:
35+
The folder structure for a C# script project looks like the following example:
3636

3737
```
3838
FunctionsProject
@@ -51,7 +51,7 @@ FunctionsProject
5151

5252
There's a shared [host.json](functions-host-json.md) file that can be used to configure the function app. Each function has its own code file (.csx) and binding configuration file (function.json).
5353

54-
The binding extensions required in [version 2.x and later versions](functions-versions.md) of the Functions runtime are defined in the `extensions.csproj` file, with the actual library files in the `bin` folder. When developing locally, you must [register binding extensions](./functions-bindings-register.md#extension-bundles). When developing functions in the Azure portal, this registration is done for you.
54+
The binding extensions required in [version 2.x and later versions](functions-versions.md) of the Functions runtime are defined in the `extensions.csproj` file, with the actual library files in the `bin` folder. When developing locally, you must [register binding extensions](./functions-bindings-register.md#extension-bundles). When you develop functions in the Azure portal, this registration is done for you.
5555

5656
## Binding to arguments
5757

@@ -373,7 +373,7 @@ The following assemblies may be referenced by simple-name, by runtime version:
373373

374374
---
375375

376-
In code, assemblies are referenced like the following:
376+
In code, assemblies are referenced like the following example:
377377

378378
```csharp
379379
#r "AssemblyName"
@@ -403,7 +403,7 @@ By default, the [supported set of Functions extension NuGet packages](functions-
403403

404404
If for some reason you can't use extension bundles in your project, you can also use the Azure Functions Core Tools to install extensions based on bindings defined in the function.json files in your app. When using Core Tools to register extensions, make sure to use the `--csx` option. To learn more, see [Install extensions](functions-run-local.md#install-extensions).
405405

406-
By default, Core Tools reads the function.json files and adds the required packages to an *extensions.csproj* C# class library project file in the root of the function app's file system (wwwroot). Because Core Tools uses dotnet.exe, you can use it to add any NuGet package reference to this extensions file. During installation, Core Tools builds the extensions.csproj to install the required libraries. Here is an example *extensions.csproj* file that adds a reference to *Microsoft.ProjectOxford.Face* version *1.1.0*:
406+
By default, Core Tools reads the function.json files and adds the required packages to an *extensions.csproj* C# class library project file in the root of the function app's file system (wwwroot). Because Core Tools uses dotnet.exe, you can use it to add any NuGet package reference to this extensions file. During installation, Core Tools builds the extensions.csproj to install the required libraries. Here's an example *extensions.csproj* file that adds a reference to *Microsoft.ProjectOxford.Face* version *1.1.0*:
407407

408408
```xml
409409
<Project Sdk="Microsoft.NET.Sdk">
@@ -418,7 +418,7 @@ By default, Core Tools reads the function.json files and adds the required packa
418418

419419
# [v1.x](#tab/functionsv1)
420420

421-
Version 1.x of the Functions runtime uses a *project.json* file to define dependencies. Here is an example *project.json* file:
421+
Version 1.x of the Functions runtime uses a *project.json* file to define dependencies. Here's an example *project.json* file:
422422

423423
```json
424424
{
@@ -438,7 +438,7 @@ Extension bundles aren't supported by version 1.x.
438438

439439
To use a custom NuGet feed, specify the feed in a *Nuget.Config* file in the function app root folder. For more information, see [Configuring NuGet behavior](/nuget/consume-packages/configuring-nuget-behavior).
440440

441-
If you are working on your project only in the portal, you'll need to manually create the extensions.csproj file or a Nuget.Config file directly in the site. To learn more, see [Manually install extensions](functions-how-to-use-azure-function-app-settings.md#manually-install-extensions).
441+
If you're working on your project only in the portal, you'll need to manually create the extensions.csproj file or a Nuget.Config file directly in the site. To learn more, see [Manually install extensions](functions-how-to-use-azure-function-app-settings.md#manually-install-extensions).
442442

443443
## Environment variables
444444

@@ -480,7 +480,7 @@ using (var output = await binder.BindAsync<T>(new BindingTypeAttribute(...)))
480480
```
481481

482482
`BindingTypeAttribute` is the .NET attribute that defines your binding and `T` is an input or output type that's
483-
supported by that binding type. `T` cannot be an `out` parameter type (such as `out JObject`). For example, the
483+
supported by that binding type. `T` can't be an `out` parameter type (such as `out JObject`). For example, the
484484
Mobile Apps table output binding supports
485485
[six output types](https://github.com/Azure/azure-webjobs-sdk-extensions/blob/master/src/WebJobs.Extensions.MobileApps/MobileTableAttribute.cs#L17-L22),
486486
but you can only use [ICollector\<T>](https://github.com/Azure/azure-webjobs-sdk/blob/master/src/Microsoft.Azure.WebJobs/ICollector.cs)
@@ -508,7 +508,7 @@ public static async Task Run(string input, Binder binder)
508508
defines the [Storage blob](functions-bindings-storage-blob.md) input or output binding, and
509509
[TextWriter](/dotnet/api/system.io.textwriter) is a supported output binding type.
510510

511-
### Multiple attribute example
511+
### Multiple attributes example
512512

513513
The preceding example 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
514514
[StorageAccountAttribute](https://github.com/Azure/azure-webjobs-sdk/blob/master/src/Microsoft.Azure.WebJobs/StorageAccountAttribute.cs)
@@ -533,7 +533,7 @@ public static async Task Run(string input, Binder binder)
533533
}
534534
```
535535

536-
The following table lists the .NET attributes for each binding type and the packages in which they are defined.
536+
The following table lists the .NET attributes for each binding type and the packages in which they're defined.
537537

538538
> [!div class="mx-codeBreakAll"]
539539
> | Binding | Attribute | Add reference |

0 commit comments

Comments
 (0)