Skip to content

Acrolinx 4/8 #28963

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 8, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ Automatic proxy detection is a process by which a Web proxy server is identified

1. The WinINet `InternetQueryOption` function is used to locate the proxy configuration script most recently detected by Internet Explorer.

2. If the script is not located, the <xref:System.Net.WebProxy> class uses the Dynamic Host Configuration Protocol (DHCP) to locate the script. The DHCP server can respond either with the location (host name) of the script or with the full URL for the script.
2. If the script isn't located, the <xref:System.Net.WebProxy> class uses the Dynamic Host Configuration Protocol (DHCP) to locate the script. The DHCP server can respond either with the location (host name) of the script or with the full URL for the script.

3. If DHCP does not identify the WPAD host, DNS is queried for a host with WPAD as its name or alias.

Expand Down Expand Up @@ -61,7 +61,7 @@ Public Shared Sub DisableForMyRequest(ByVal resource As Uri)
End Sub
```

Requests that do not have a proxy use your application domain's default proxy, which is available in the <xref:System.Net.WebRequest.DefaultWebProxy%2A> property.
Requests that don't have a proxy use your application domain's default proxy, which is available in the <xref:System.Net.WebRequest.DefaultWebProxy%2A> property.

## See also

Expand Down
4 changes: 2 additions & 2 deletions docs/standard/commandline/dependency-injection.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,8 +17,8 @@ Use a [custom binder](model-binding.md#model-binding-more-than-16-options-and-ar

We recommend handler-specific dependency injection (DI) for the following reasons:

* Command-line apps are often short-lived processes, in which startup cost can have a noticeable impact on performance. Optimizing performance is particularly important when tab completions have to be calculated. Unlike Web and GUI apps, which tend to be relatively long-lived processes, CLI apps are often short lived processes. Unnecessary startup time is not appropriate for short-lived processes, .
* When a command line app that has multiple subcommands is run, only one of those subcommands will be executed. If an app configures dependencies for the subcommands that don't run, it needlessly degrades performance.
* Command-line apps are often short-lived processes, in which startup cost can have a noticeable impact on performance. Optimizing performance is particularly important when tab completions have to be calculated. Command-line apps are unlike Web and GUI apps, which tend to be relatively long-lived processes. Unnecessary startup time is not appropriate for short-lived processes.
* When a command-line app that has multiple subcommands is run, only one of those subcommands will be executed. If an app configures dependencies for the subcommands that don't run, it needlessly degrades performance.

To configure DI, create a class that derives from <xref:System.CommandLine.Binding.BinderBase%601> where `T` is the interface that you want to inject an instance for. In the <xref:System.CommandLine.Binding.BinderBase%601.GetBoundValue%2A> method override, get and return the instance you want to inject. The following example injects the default logger implementation for <xref:Microsoft.Extensions.Logging.ILogger>:

Expand Down
6 changes: 3 additions & 3 deletions docs/standard/commandline/use-middleware.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,11 +13,11 @@ ms.topic: how-to

[!INCLUDE [scl-preview](../../../includes/scl-preview.md)]

This article explains how to work with middleware in command-line apps that are built with the `System.CommandLine` library. This is an advanced topic that most `System.CommandLine` users will not need to consider.
This article explains how to work with middleware in command-line apps that are built with the `System.CommandLine` library. Use of middleware is an advanced topic that most `System.CommandLine` users won't need to consider.

## Introduction to middleware

While each command has a handler that `System.CommandLine` will route to based on input, there is also a mechanism for short-circuiting or altering the input before your application logic is invoked. In between parsing and invocation, there is a chain of responsibility, which you can customize. A number of built-in features of `System.CommandLine` make use of this capability. This is how the `--help` and `--version` options short-circuit calls to your handler.
While each command has a handler that `System.CommandLine` will route to based on input, there's also a mechanism for short-circuiting or altering the input before your application logic is invoked. In between parsing and invocation, there's a chain of responsibility, which you can customize. A number of built-in features of `System.CommandLine` make use of this capability. This is how the `--help` and `--version` options short-circuit calls to your handler.

Each call in the pipeline can take action based on the <xref:System.CommandLine.Parsing.ParseResult> and return early, or choose to call the next item in the pipeline. The `ParseResult` can even be replaced during this phase. The last call in the chain is the handler for the specified command.

Expand All @@ -27,7 +27,7 @@ You can add a call to this pipeline by calling <xref:System.CommandLine.Builder.

:::code language="csharp" source="snippets/use-middleware/csharp/Program.cs" id="middleware" :::

In the preceding code, the middleware writes out "Hi!" if the directive `[just-say-hi]` is found in the parse result. When this happens, the command's normal handler isn't invoked. It isn't invoked because the middleware does not call the `next` delegate.
In the preceding code, the middleware writes out "Hi!" if the directive `[just-say-hi]` is found in the parse result. When this happens, the command's normal handler isn't invoked. It isn't invoked because the middleware doesn't call the `next` delegate.

In the example, `context` is <xref:System.CommandLine.Invocation.InvocationContext>, a singleton structure that acts as the "root" of the entire command-handling process. This is the most powerful structure in `System.CommandLine`, in terms of capabilities. There are two main uses for it in middleware:

Expand Down