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

[GitHubber17]

This PR contains light freshness updates to the following articles:

• Access HttpContext in ASP.NET Core

  • Removed duplicate content in moniker sections
  • 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?
  • 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
  • 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
  • Tom or Wade - Address Build Warning "No intersection between zone and file level monikers."
  • 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."
  • 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.

[ Note from Wade: I updated this to address by myself and Tom, since this is Tom's content. ]

---

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. However, the instruction in the article is actually technically correct (but really confusing and could be written better); it is referring refers 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.