Light Freshness Edit: ASP.NET - HTTP + Native AOT + Kestrel

[GitHubber17]

This PR contains light freshness updates to the following articles:

[ Additional note from Wade: I updated the questions to address Tom, in addition to myself, since this is Tom's content. ]

• Access HttpContext in ASP.NET Core

  • Removed duplicate content in moniker sections
  • [Answered by Wade below]Tom or Wade (Tom's docs) - The SignalR and gRPC sections are visible only in moniker range >= 6.0,
    but article descriptions for both ranges say SignalR and gRPC are supported.
    Should the two sections be visible for both moniker ranges?
  • [Answered by Wade below]Tom or Wade - In the custom components section, the example code is very similar for both moniker ranges.
    Could the example for the >=6.0 range work for both article versions?

• Make HTTP requests using IHttpClientFactory in ASP.NET Core

  • Refreshed content within moniker range >= 6.0 only; Otherwise, updated for Acrolinx
    -[Answered by Wade below] Tom or Wade - Line 223: I found no "/Operation" (or similar) folder in the GH repo per the instruction
    "In the HttpRequestsSample download, go to the /Operation folder..."

• ASP.NET Core support for Native AOT

  • Updated include file, /fundamentals/aot/includes/aot_lib.md
  • [Answered by Wade in discussion below.] Tom or Wade - Address Build Warning "No intersection between zone and file level monikers."
    -[Answered by Wade in discusison below] Tom or Wade - Line 298: Context needed for statement "A parameter on the delegate that isn't bound to the body..."

• Configure endpoints for the ASP.NET Core Kestrel web server

  • Updated include files, ~includes/credentials-warning.md, http-ports.md, make-x509-cert.md
  • Tom or Wade - Address Build Warning "No intersection between zone and file level monikers."
  • [Seems resolved now, see answer below] Tom or Wade - Line 129: Provide updated <xref> link syntax for broken link, here is the URL
  • Tom or Wade - Line 140, Confirm link is accurate, API might be changed, "The loader's .... method"
    <xref:Microsoft.AspNetCore.Server.Kestrel.KestrelConfigurationLoader.Endpoint...

For details, see ADO request 568764.

---

Internal previews

📄 File	🔗 Preview link
aspnetcore/fundamentals/http-context.md	customer intent: As an ASP.NET developer, I want to understand how to access HttpContext in my ASP.NET Core apps, so I can address related exceptions and thread issues.
aspnetcore/fundamentals/http-requests.md	HTTP Requests with IHttpClientFactory - ASP.NET Core
aspnetcore/fundamentals/native-aot.md	ms.author: midenn (Mitch Denny)
aspnetcore/fundamentals/servers/kestrel/endpoints.md	Configure endpoints for the ASP.NET Core Kestrel web server

[wadepickett]

@GitHubber17, looks like there are some moniker-versining issues. See the details by clicking the OpenPublishing.Build link for details:

[GitHubber17]

@wadepickett - I did look at the Build report. Please see my notes for you in the top comment. Thanks

[wadepickett]

• s?

@wadepickett - I did look at the Build report. Please see my notes for you in the top comment. Thanks

Oh, whoops, sorry, I should have read through that first.

[wadepickett]

"Wade - In the custom components section, the example code is very similar for both moniker ranges.
Could the example for the >=6.0 range work for both article versions?"

Good question, thanks. It could not work for both versions. The two code samples are fundamentally different because of the hosting model change:

= 6.0 uses WebApplication.CreateBuilder(args) (minimal hosting)
< 6.0 uses Startup.ConfigureServices(IServiceCollection services) (classic hosting)
These are not interchangeable. The UserRepository example code is similar in both, but the DI registration code is structurally different. Keep both moniker-specific code blocks. You can however share the explanatory text while only splitting the code blocks.

Going forward, I would discontinue consolidating overlap between versions as a goal, and instead focus only on improving the latest version (which will be carried forward). There was almost always a reason for keeping very near-identical code and instructions separate. Differences can look really minor, but any inaccuracy between versions can render that version's content guidance useless and untrustworthy for development. It would also require significant resources to go back and re-test all the older content and code versions against their respective frameworks and packages for what are editorial rather then technical focused updates.
For future PRs involving these light freshness updates, I think we should edit only the latest version and carry those improvements forward, preserving technical integrity, which is absolutely paramount.

[wadepickett]

@GitHubber17 , for this question:
"The SignalR and gRPC sections are visible only in moniker range >= 6.0,
but article descriptions for both ranges say SignalR and gRPC are supported.
Should the two sections be visible for both moniker ranges?"

It should all look like this I think:

"## Access HttpContext from middleware"
(shared across all versions — already correct)

"## Access HttpContext from SignalR"
(move outside moniker gate — applies to >= 3.1)

"## Access HttpContext from gRPC methods"
(move outside moniker gate — applies to >= 3.1)

"## Access HttpContext from custom components"
(shared across all versions — already correct)

[wadepickett]

@GitHubber17
For this question:
"Line 223: I found no "/Operation" (or similar) folder in the GH repo per the instruction
"In the HttpRequestsSample download, go to the /Operation folder...""

Correct there is no /Operation folder in the repo. The instruction in the article is actually technically correct (but really confusing and could be written better); it is referring to a page route, not a file system folder. Good catch, it does need help.

Pages/Operation.cshtml is a file in the project, and /Operation is the route (URL) a developer navigates to in the browser when running the app. They're connected by convention, no explicit route registration is needed.

The original article text was confusing. When it said "go to the /Operation folder," there's no folder, there's a Pages/Operation.cshtml file that produces a /Operation route. The article meant "navigate to https://localhost:{PORT}/Operation in your browser."

How to correct this:
The original text should have said somethiing like this to clarify:
In the HttpRequestsSample download, run the app and navigate to the /Operation page, then refresh.

I will add the suggestion inline.

[wadepickett]

Fro this question:
Tom or Wade - Address Build Warning "No intersection between zone and file level monikers."

For the native-aot.md:
Adding monikerRange: '>= aspnetcore-9.0' to the file-level front matter seems to conflict with the include at line 306 ([!INCLUDE]), which targets .NET 8 and looks ilke the source of the build warning "No intersection between zone and file level monikers."

Original before the PR:
(no monikerRange in front matter)

...
:::moniker range=">= aspnetcore-9.0"
(main content)
:::moniker-end
[!INCLUDE[](~/fundamentals/native-aot/includes/native-aot8.md)]

The PR changed it to:

monikerRange: '>= aspnetcore-9.0'
(in front matter, inline moniker wrapper removed)
...
[!INCLUDE[](~/fundamentals/native-aot/includes/native-aot8.md)]

To fix I think:

Remove monikerRange: '>= aspnetcore-9.0' from the front matter and restore the inline :::moniker range=">= aspnetcore-9.0" / :::moniker-end wrapper around the main article content (just before the include). The original article had this structure, and it worked because:

• The file-level moniker was unset (allowing all versions)
• The main body was wrapped in :::moniker range=">= aspnetcore-9.0"
• The include file at the bottom provides the = aspnetcore-8.0 version via its own internal :::moniker range="= aspnetcore-8.0" gate

The PR broke this by setting the file-level moniker to >= aspnetcore-9.0, which makes the .NET 8 include's = aspnetcore-8.0 range have no intersection with the file, hence the build warning.

[wadepickett]

For question: "Tom or Wade - Line 298: Context needed for statement "A parameter on the delegate that isn't bound to the body..."

This sentence, original to the file, is an orphaned fragment that lacks context. It reads as a standalone statement but doesn't connect to anything. I didin't write this article and I'm not sure of the author's intent. Here is what I would guess was trying to be said:

A parameter on the delegate that isn't bound to the body **doesn't** need to be serializable. For example, a query string parameter can be a rich object type that implements `IParsable<T>`.

@tdykstra, that sound right?

[wadepickett]

For this question related to build warning for Configure endpoints for the ASP.NET Core Kestrel web server

Updated include files, ~includes/credentials-warning.md, http-ports.md, make-x509-cert.md
Tom or Wade - Address Build Warning "No intersection between zone and file level monikers."

The original file on main had:

File-level: monikerRange: '>= aspnetcore-5.0' (broad, covers everything)
Inline wrapper: :::moniker range=">= aspnetcore-8.0" around the main body
Include at bottom: endpoints5-7.md with its own = aspnetcore-7.0 and = aspnetcore-6.0 gates
That worked fine, the file-level range was wide enough to encompass all the inline moniker zones.

The PR changed the file-level range to '>= aspnetcore-8.0' and removed the inline wrapper, which broke the include. Same thing happened with native-aot.md (file-level narrowed to '>= aspnetcore-9.0', breaking the .NET 8 include).

To fix I, I think:
For file: aspnetcore/fundamentals/servers/kestrel/endpoints.md
Remove monikerRange: '>= aspnetcore-8.0' from the front matter and restore the original '>= aspnetcore-5.0' (or maybe the monikerRange could be removed entirely as an alternative).

[wadepickett]

In endpoint.md:
For this question:
Tom or Wade - Line 129: Provide updated link syntax for broken link, here is the URL

For this link on line 129:
By default, the endpoint configuration can be reloaded when the configuration source changes. It can be disabled by using the xref:Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerOptions.Configure(Microsoft.Extensions.Configuration.IConfiguration,System.Boolean) method.

This resolves fine at the moment when I click on the link in build. Maybe there was a review build issue at the moment when you happen tobe checking it last as a guess.